On Tue, 10 Mar 2020 at 08:19, Alexander von Gluck IV
<kallisti5@xxxxxxxxxxx> wrote:
March 9, 2020 12:56 PM, "waddlesplash" <waddlesplash@xxxxxxxxx> wrote:
On Mon, Mar 9, 2020, 12:36 PM Alex von Gluck IV <kallisti5@xxxxxxxxxxx> wrote:
index b420ae037d..e871b236bd 100644
--- a/src/system/boot/platform/efi/start.cpp
+++ b/src/system/boot/platform/efi/start.cpp
@@ -43,7 +43,7 @@ efi_handle kImage;
static uint32 sBootOptions;
-
+void* gFDT;
extern "C" int main(stage2_args *args);
extern "C" void _start(void);
@@ -177,6 +177,7 @@ extern "C" efi_status
efi_main(efi_handle image, efi_system_table *systemTable)
{
stage2_args args;
+ gFDT = NULL;
memset(&args, 0, sizeof(stage2_args));
-2, this should not have been merged and should be reverted. If this is
absolutely needed, it can happen in ARM arch code, but not here.
-waddlesplash
I didn't really see this as a huge deal.
1) fdt in EFI is completely a thing.
https://github.com/ARM-software/u-boot/blob/master/doc/README.uefi#L33
2) fdt isn't arm-only (our ppc code uses it as well)
3) fdt isn't "going away" as commented in IRC.
The reasoning was the FDT bus_manager depends on gFDT as well as a lot of the
mmu code. I was trying
to get an "buildable/bootable" arm EFI loader without going down several
rabbit holes. It's hard to
create functioning code without the ability to test it on hardware or qemu.
*However*, since it's become such a big issue (and I didn't do a review for
it since I didn't see it as a big deal),
i'm reverting the gFDT portion of that commit.