efi/x86_64: skip reserved memory blocks when finding out the memory top

fix #16712

Change-Id: Ib2ae08bc47008098a6b0c231a759d5e91f88fd33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5912
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

boot/efi/x86_64: log memory map on bootup

Change-Id: I94c169d598d771a813b16e31fd892d7cdafcaad8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5687
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

boot/efi/arch: remove comments related to ConvertPointer

Change-Id: I1c0ebe04c180f3c50ac07c7d043a33d2c4563a18
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4924
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>

boot: rework 32-bit/64-bit kernel load base selection

Change-Id: I0aed05c0ef2ff1a162581e4f988bf24ed1e521e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4816
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>

boot/platform/efi/arch/x86_64: fix -Warray-bounds

Size of gBootGDT[] is 'USER_DATA_SEGMENT + 1' defined at line 26,
and it equals USER_CODE_SEGMENT, so gBootGDT[USER_CODE_SEGMENT]
is out of bounds at line 44.

Change-Id: I1374f4d1185b6a47f910ac128d49a07cdd80d925
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4536
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

bootloader: Split memory map handling into add/remove passes.

The memory map may be unordered and include overlapping ranges. To make
sure that nothing gets included as usable that should actually be
excluded, first scan for all usable ranges and add them, then remove
anything unusable from these ranges again.

To calculate the amount of unusable memory, count the total after the
first pass and then subtract the total after the second. This way, only
unusable ranges that actually overlap physical memory (and therefore
reduce the amount of usable memory) get excluded.

Note that the explicit ignore of the ACPI reclaim memory is subsumed by
the above. We still don't want to add this region to the usable memory
map, as that would allow the kernel to allocate pages into that region,
possibly corrupting ACPI tables before they were used. We also don't
want to add it as an allocated range, as it is not guaranteed that ACPI
is done with the tables before the unused bootloader ranges are freed in
the kernel.

Also add the missing unusable memory amount from ignoring the first MiB
of memory in the EFI loader.

May fix #16056 although it is not certain that graphics memory ranges
are actually included in the memory map.

Change-Id: Ie7991d2c4dcd988edac2995b3a7efc509fa0f4a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2814
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

EFI: Make our haiku_loader architecture agnostic

* This is the bulk of the work. Anything else should be
minor cleanups and tweaking.
* riscv64 isn't a viable EFI platform yet.. just acting
as a stand-in to test a non-x86 EFI haiku_loader

Change-Id: Ib03de81e2b562e693987b86d7b4318209fb1c792
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2256
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

boot/platform: Break x86 code away from core EFI code

Change-Id: I88afad6d071e8b577c23da9c60392c60b3726514
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1895
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>