History log of /u-boot/lib/efi_loader/efi_memory.c
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# b34ce311 05-Apr-2024 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: eliminate duplicate runtime section definitions

The following symbols are defined in two includes:

* __efi_runtime_start[]
* __efi_runtime_stop[]
* __efi_runtime_rel_start[]
* __efi_runtime_rel_stop[]

Eliminate the definitions in efi_loader.h.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# c1624846 04-Apr-2024 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: access __efi_runtime_start/stop without &

A symbol defined in a linker script (e.g. __efi_runtime_start = .;) is
only a symbol, not a variable and should not be dereferenced.
The common practice is either define it as
extern uint32_t __efi_runtime_start or
extern char __efi_runtime_start[] and access it as
&__efi_runtime_start or __efi_runtime_start respectively.

So let's access it properly since we define it as an array

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# c38cb227 14-Dec-2023 Tom Rini <trini@konsulko.com>

efi_loader: Remove <common.h>

We largely do not need <common.h> in these files, so drop it. The only
exception here is that efi_freestanding.c needs <linux/types.h> and had
been getting that via <common.h>.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# b571b3ac 13-Aug-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix efi_add_known_memory()

In efi_add_known_memory() we currently call board_get_usable_ram_top() with
an incorrect value 0 of parameter total_size. This leads to an incorrect
value for ram_top depending on the code in board_get_usable_ram_top().

Use the value of gd->ram_top instead which is set before relocation by
calling board_get_usable_ram_top().

Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ecae4bbf 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: memory leak efi_add_memory_map_pg

Don't leak newlist if we error out.

Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 257a498f 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_mem_carve_out

Handle out of memory situation in efi_mem_carve_out().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 48d183f2 30-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: overflow in efi_allocate_pages

On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which
does not occur in 64bit arithmetics.

An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated
as an error.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ba275630 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_add_memory_map_pg

Handle out of memory situation in efi_add_memory_map_pg().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 207b6864 05-Apr-2023 Bin Meng <bmeng@tinylab.org>

efi: loader: Make efi_mem static

efi_mem is only referenced in efi_memory.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>

# f606fab8 19-Mar-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: move dp_alloc() to efi_alloc()

The incumbent function efi_alloc() is unused.

Replace dp_alloc() by a new function efi_alloc() that we can use more
widely.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 0763c02e 07-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix description of memory functions

* Add missing function descriptions
* Adjust to Sphinx style

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# eff44401 05-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: carve out efi_get_memory_map_alloc()

Carve out code from efidebug command used to read the memory map.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# c1624846 04-Apr-2024 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: access __efi_runtime_start/stop without &

A symbol defined in a linker script (e.g. __efi_runtime_start = .;) is
only a symbol, not a variable and should not be dereferenced.
The common practice is either define it as
extern uint32_t __efi_runtime_start or
extern char __efi_runtime_start[] and access it as
&__efi_runtime_start or __efi_runtime_start respectively.

So let's access it properly since we define it as an array

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# c38cb227 14-Dec-2023 Tom Rini <trini@konsulko.com>

efi_loader: Remove <common.h>

We largely do not need <common.h> in these files, so drop it. The only
exception here is that efi_freestanding.c needs <linux/types.h> and had
been getting that via <common.h>.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# b571b3ac 13-Aug-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix efi_add_known_memory()

In efi_add_known_memory() we currently call board_get_usable_ram_top() with
an incorrect value 0 of parameter total_size. This leads to an incorrect
value for ram_top depending on the code in board_get_usable_ram_top().

Use the value of gd->ram_top instead which is set before relocation by
calling board_get_usable_ram_top().

Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ecae4bbf 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: memory leak efi_add_memory_map_pg

Don't leak newlist if we error out.

Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 257a498f 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_mem_carve_out

Handle out of memory situation in efi_mem_carve_out().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 48d183f2 30-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: overflow in efi_allocate_pages

On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which
does not occur in 64bit arithmetics.

An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated
as an error.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ba275630 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_add_memory_map_pg

Handle out of memory situation in efi_add_memory_map_pg().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 207b6864 05-Apr-2023 Bin Meng <bmeng@tinylab.org>

efi: loader: Make efi_mem static

efi_mem is only referenced in efi_memory.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>

# f606fab8 19-Mar-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: move dp_alloc() to efi_alloc()

The incumbent function efi_alloc() is unused.

Replace dp_alloc() by a new function efi_alloc() that we can use more
widely.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 0763c02e 07-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix description of memory functions

* Add missing function descriptions
* Adjust to Sphinx style

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# eff44401 05-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: carve out efi_get_memory_map_alloc()

Carve out code from efidebug command used to read the memory map.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# c38cb227 14-Dec-2023 Tom Rini <trini@konsulko.com>

efi_loader: Remove <common.h>

We largely do not need <common.h> in these files, so drop it. The only
exception here is that efi_freestanding.c needs <linux/types.h> and had
been getting that via <common.h>.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# b571b3ac 13-Aug-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix efi_add_known_memory()

In efi_add_known_memory() we currently call board_get_usable_ram_top() with
an incorrect value 0 of parameter total_size. This leads to an incorrect
value for ram_top depending on the code in board_get_usable_ram_top().

Use the value of gd->ram_top instead which is set before relocation by
calling board_get_usable_ram_top().

Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ecae4bbf 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: memory leak efi_add_memory_map_pg

Don't leak newlist if we error out.

Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 257a498f 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_mem_carve_out

Handle out of memory situation in efi_mem_carve_out().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 48d183f2 30-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: overflow in efi_allocate_pages

On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which
does not occur in 64bit arithmetics.

An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated
as an error.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ba275630 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_add_memory_map_pg

Handle out of memory situation in efi_add_memory_map_pg().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 207b6864 05-Apr-2023 Bin Meng <bmeng@tinylab.org>

efi: loader: Make efi_mem static

efi_mem is only referenced in efi_memory.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>

# f606fab8 19-Mar-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: move dp_alloc() to efi_alloc()

The incumbent function efi_alloc() is unused.

Replace dp_alloc() by a new function efi_alloc() that we can use more
widely.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 0763c02e 07-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix description of memory functions

* Add missing function descriptions
* Adjust to Sphinx style

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# eff44401 05-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: carve out efi_get_memory_map_alloc()

Carve out code from efidebug command used to read the memory map.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# b571b3ac 13-Aug-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix efi_add_known_memory()

In efi_add_known_memory() we currently call board_get_usable_ram_top() with
an incorrect value 0 of parameter total_size. This leads to an incorrect
value for ram_top depending on the code in board_get_usable_ram_top().

Use the value of gd->ram_top instead which is set before relocation by
calling board_get_usable_ram_top().

Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ecae4bbf 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: memory leak efi_add_memory_map_pg

Don't leak newlist if we error out.

Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 257a498f 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_mem_carve_out

Handle out of memory situation in efi_mem_carve_out().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 48d183f2 30-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: overflow in efi_allocate_pages

On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which
does not occur in 64bit arithmetics.

An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated
as an error.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ba275630 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_add_memory_map_pg

Handle out of memory situation in efi_add_memory_map_pg().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 207b6864 05-Apr-2023 Bin Meng <bmeng@tinylab.org>

efi: loader: Make efi_mem static

efi_mem is only referenced in efi_memory.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>

# f606fab8 19-Mar-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: move dp_alloc() to efi_alloc()

The incumbent function efi_alloc() is unused.

Replace dp_alloc() by a new function efi_alloc() that we can use more
widely.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 0763c02e 07-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix description of memory functions

* Add missing function descriptions
* Adjust to Sphinx style

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# eff44401 05-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: carve out efi_get_memory_map_alloc()

Carve out code from efidebug command used to read the memory map.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# ecae4bbf 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: memory leak efi_add_memory_map_pg

Don't leak newlist if we error out.

Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 257a498f 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_mem_carve_out

Handle out of memory situation in efi_mem_carve_out().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 48d183f2 30-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: overflow in efi_allocate_pages

On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which
does not occur in 64bit arithmetics.

An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated
as an error.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ba275630 29-Jul-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of memory in efi_add_memory_map_pg

Handle out of memory situation in efi_add_memory_map_pg().

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 207b6864 05-Apr-2023 Bin Meng <bmeng@tinylab.org>

efi: loader: Make efi_mem static

efi_mem is only referenced in efi_memory.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>

# f606fab8 19-Mar-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: move dp_alloc() to efi_alloc()

The incumbent function efi_alloc() is unused.

Replace dp_alloc() by a new function efi_alloc() that we can use more
widely.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 0763c02e 07-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix description of memory functions

* Add missing function descriptions
* Adjust to Sphinx style

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# eff44401 05-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: carve out efi_get_memory_map_alloc()

Carve out code from efidebug command used to read the memory map.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <masahiroy@kernel.org>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# 207b6864 05-Apr-2023 Bin Meng <bmeng@tinylab.org>

efi: loader: Make efi_mem static

efi_mem is only referenced in efi_memory.c

Signed-off-by: Bin Meng <bmeng@tinylab.org>

# f606fab8 19-Mar-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: move dp_alloc() to efi_alloc()

The incumbent function efi_alloc() is unused.

Replace dp_alloc() by a new function efi_alloc() that we can use more
widely.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 0763c02e 07-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix description of memory functions

* Add missing function descriptions
* Adjust to Sphinx style

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# eff44401 05-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: carve out efi_get_memory_map_alloc()

Carve out code from efidebug command used to read the memory map.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# 0763c02e 07-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix description of memory functions

* Add missing function descriptions
* Adjust to Sphinx style

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# eff44401 05-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: carve out efi_get_memory_map_alloc()

Carve out code from efidebug command used to read the memory map.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# eff44401 05-Jan-2023 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: carve out efi_get_memory_map_alloc()

Carve out code from efidebug command used to read the memory map.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# 1a127962 29-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: don't use EFI_LOADER_DATA internally

EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.

Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# 53def68d 05-Nov-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAddress requires page address

AllocatePages() can be called with Type=AllocateAddress. Such a call can
only succeed if *Memory points to the address of an unallocated page range.

A call with *Memory being an address that is not page aligned must not
succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES
if the requested pages cannot be allocated.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# 8da26f51 25-Apr-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_add_conventional_memory_map()

Remove redundant constraint.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# 185f812c 19-Jan-2022 Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: replace @return by Return:

Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# ebdea88d 11-Oct-2021 Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_loader: Fix loaded image alignment

We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).

So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.

[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# 49d225e7 17-Aug-2021 Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: use correct type for AllocatePages, AllocatePool

Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().

In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>

# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>

# 7b05667c 16-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>

# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>

# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>

# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>

# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 282a06cb 18-Jun-2018 Alexander Graf <agraf@csgraf.de>

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>

# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>

# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>

# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>

# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>

# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>

# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>

# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>

# c6e3c3e6 21-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 0ecba5db 21-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 71275a3e 14-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>

# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>

# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>

# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>

# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>

# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>

# 74c16acc 26-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# edcef3ba 02-Jun-2016 Alexander Graf <agraf@csgraf.de>

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>

# 51735ae0 11-May-2016 Alexander Graf <agraf@csgraf.de>

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>

# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>

# cee752fa 11-Apr-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>

# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

# 5d00995c 03-Mar-2016 Alexander Graf <agraf@csgraf.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# db0f2984 05-Jan-2021 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: remove outdated TODO in efi_memory.c

In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# ffbeafe7 28-Aug-2020 Maxim Uvarov <maxim.uvarov@linaro.org>

efi_memory: refine overlap_only_ram description

Refine text for overlap_only_ram description to
match to what exactly flag does and aling description
with other functions.

Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 74b869ba 28-Jul-2020 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system

The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.

Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 90526e9f 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop net.h from common header

Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 714497e3 16-May-2020 Michael Walle <michael@walle.cc>

efi_loader: round the memory area in efi_add_memory_map()

Virtually all callers of this function do the rounding on their own.
Some do it right, some don't. Instead of doing this in each caller,
do the rounding in efi_add_memory_map(). Change the size parameter
to bytes instead of pages and remove aligning and size calculation in
all callers.

There is no more need to make the original efi_add_memory_map() (which
takes pages as size) available outside the module. Thus rename it to
efi_add_memory_map_pg() and make it static to prevent further misuse
outside the module.

Signed-off-by: Michael Walle <michael@walle.cc>
Add missing comma in sunxi_display.c.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# b484296f 11-Mar-2020 AKASHI Takahiro <takahiro.akashi@linaro.org>

efi_loader: get_memory_map: return parameters whenever possible

Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.

While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.

With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@csgraf.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@csgraf.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 67c4e9f8 14-Nov-2019 Simon Glass <sjg@chromium.org>

common: Move board_get_usable_ram_top() out of common.h

Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7264e21f 08-Nov-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: call add_u_boot_and_runtime() on sandbox

On the sandbox we should mark the stack area as EFI runtime memory like we
do on any other architecture.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# b5b9eff2 03-Sep-2019 Park, Aiden <aiden.park@intel.com>

efi_loader: Extract adding a conventional memory in separate routine

Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.

Signed-off-by: Aiden Park <aiden.park@intel.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 4be077b2 13-Jul-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix comment for struct efi_pool_allocation

Change comment for struct efi_pool_allocation to match Sphinx style.
Describe all structure fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# b225c92f 14-Jul-2019 Bryan O'Donoghue <pure.logic@nexus-software.ie>

efi_loader: Change return type of efi_add_memory_map()

We currently have some inconsistent use of efi_add_memory_map()
throughout the code. In particular the return value of efi_add_memory_map()
is not interpreted the same way by various users in the codebase.

This patch does the following:

- Changes efi_add_memory_map() to return efi_status_t.
- Adds a method description to efi_add_memory_map().
- Changes efi_add_memory_map() to return EFI_SUCCESS
- Returns non-zero for error in efi_add_memory_map()
- Updates efi_allocate_pages() to new efi_add_memory_map()
- Updates efi_free_pages() to new efi_add_memory_map()
- Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
- Updates efi_add_runtime_mmio() to new efi_add_memory_map()

Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 0e22c7cb 11-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocatePages() must accept addr == 0

It must be possible to allocate memory at address 0 with AllocatePages().

Move a NULL pointer check.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7eaa900e 06-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: event signaling in ExitBootServices

ExitBootServices() has to stop timer related activity before calling the
events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
current implementation was stopping all other events.

All events have to observe the task priority level.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e80474ad 04-Jun-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: notify memory map changes

When the memory map is changed signal events of the
EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 8ae39857 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: simplify efi_allocate_pages()

Replace unnecessary control structures by using return statements.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f756fe83 11-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: AllocateAdress error handling

If AllocatePages() is called with AllocateAddress, the UEFI spec requires
to return EFI_NOT_FOUND in case the memory page does not exist.

The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if
the page is already allocated.

Check that *Memory refers to an unallocated page.

UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 735fd228 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: out of resources in AllocatePages()

According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 7d3af58e 10-May-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory address before freeing

When we call FreePages() we essentially add memory to our memory map. We
shouldn't do this for memory that does not exit.

Check if the memory that is to be freed via FreePages() or FreePool() is in
our memory map and is not EFI_CONVENTIONAL_MEMORY.

This check is mandated by the UEFI specification.

Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e00b82db 25-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# f12bcc91 22-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: check memory type in AllocatePages()

The UEFI specification prescribes that AllocatePages() checks the memory
type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 9631fa0f 11-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: update virtual address in efi_mem_carve_out

Handle virtual address in efi_mem_carve_out() function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

At boottime physical and virtual addressed have to be the same.
This allowed to simplify the proposed logic.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# e301e024 04-Apr-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 2c3ec289 25-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 306b1671 18-Mar-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>


# 23f5f4ab 05-Jan-2019 Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix memory allocation on sandbox

Commit 7b78d6438a2b ("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 49759743bf09 ("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: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a2b ("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>


# 7a82c305 17-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# c3772ca1 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 49759743 18-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 7b78d643 30-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 108bdff8 12-Nov-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# c2e1ad70 04-Nov-2018 Alexander Graf <agraf@suse.de>

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>


# 7b05667c 16-Sep-2018 Alexander Graf <agraf@suse.de>

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>


# 14deb5e6 30-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""

This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710.

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>


# dee37fc9 06-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>


# 9b89183b 14-Jul-2018 Eugeniu Rosca <roscaeugeniu@gmail.com>

efi: Fix truncation of constant value

Starting with commit 867a6ac86dd8 ("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: 867a6ac86dd8 ("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>


# fa995d0d 06-Aug-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>


# ccfc78b8 02-Aug-2018 Stephen Warren <swarren@nvidia.com>

Revert "efi_loader: efi_allocate_pages is too restrictive"

This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. 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>


# 1fcb7ea2 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 8e835554 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 4d5e071e 01-Jul-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 282a06cb 18-Jun-2018 Alexander Graf <agraf@suse.de>

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>


# 69259b83 18-Jun-2018 Simon Glass <sjg@chromium.org>

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>


# aa909462 18-Jun-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 32826140 27-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# e09159c8 26-May-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 1f0532ca 27-Apr-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# f739fcd8 07-May-2018 Tom Rini <trini@konsulko.com>

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: 83d290c56fab ("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>


# bdecaebd 08-Mar-2018 Simon Glass <sjg@chromium.org>

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>


# 7c92fd69 30-Jan-2018 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# b08c8c48 04-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

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>


# 474a6f5a 04-Dec-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# f5a2a938 06-Nov-2017 Heinrich Schuchardt <xypron.glpk@gmx.de>

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>


# 946160f3 13-Sep-2017 Rob Clark <robdclark@gmail.com>

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>


# a1b24823 26-Jul-2017 Rob Clark <robdclark@gmail.com>

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>


# c6e3c3e6 21-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>


# 0ecba5db 21-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>


# 71275a3e 14-Jul-2017 xypron.glpk@gmx.de <xypron.glpk@gmx.de>

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>


# 42633745 06-Mar-2017 York Sun <york.sun@nxp.com>

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>


# 511d0b97 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>


# b6a95172 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>


# b61d857b 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>


# 42417bc8 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>


# ead1274b 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>


# bdf5c1b3 09-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

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>


# 852efbf5 01-Oct-2016 Stefan Brüns <stefan.bruens@rwth-aachen.de>

efi_loader: Update description of internal efi_mem_carve_out

In 74c16acce30bb882ad5951829d8dafef8eea564c 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>


# 4c02c11d 05-Sep-2016 Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>

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>


# c933ed94 16-Jul-2016 Andreas Färber <afaerber@suse.de>

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>


# 74c16acc 26-May-2016 Alexander Graf <agraf@suse.de>

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>


# edcef3ba 02-Jun-2016 Alexander Graf <agraf@suse.de>

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>


# 51735ae0 11-May-2016 Alexander Graf <agraf@suse.de>

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>


# dede284d 13-Apr-2016 Andreas Färber <afaerber@suse.de>

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>


# cee752fa 11-Apr-2016 Alexander Graf <agraf@suse.de>

efi_loader: Expose ascending efi memory map

The EFI memory map does not need to be in a strict order, but 32bit
grub2 does expect it to be ascending. If it's not, it may try to
allocate memory inside the U-Boot data memory region.

We already sort the memory map in descending order, so let's just
reverse it when we pass it to a payload.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>


# 38ce65e1 30-Mar-2016 Alexander Graf <agraf@suse.de>

efi_loader: Always allocate the highest available address

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>


# 5d00995c 03-Mar-2016 Alexander Graf <agraf@suse.de>

efi_loader: Implement memory allocation and map

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: Alexander Graf <agraf@suse.de>
Tested-by: Simon Glass <sjg@chromium.org>