On 1/19/19 12:55 PM, Heinrich Schuchardt wrote: > On 1/19/19 11:21 AM, Heinrich Schuchardt wrote: >> Hello Alex, >> >> bootefi hello fails since 5be444d14b380b210b246aa73dd5a111e4b1f80d >> efi_loader: consistent build flags for EFI applications >> >> The problem is caused by incorrect entry point information in the EFI >> binary: >> >> Actual positions in EFI file: >> 0x178 hw_memcmp.constprop.0 >> 0x1a8 efi_main >> >> Header information in EFI file >> (using https://github.com/xypron/efi_analyzer): >> >> BaseOfCode=0x148 >> AddressOfEntryPoint=0x148 >> >> So AddressOfEntryPoint is not pointing to efi_main(). > > In arch/arm/lib/crt0_aarch64_efi.S we define AddressOfEntryPoint to > point to _start. _start() calls _relocate(). > > We already do a relocation in efi_load_pe(). I cannot understand why the > code should be relocated twice. > > Best regards > > Heinrich >
Though I still do not understand why we call relocation twice the real bug seems to stem form a call to a non-existent memcpy() function. See address 0x74 of the disassembly. https://gcc.gnu.org/onlinedocs/gcc/Standards.html teaches: "GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp." struct efi_simple_text_output_protocol *con_out = systable->con_out; 60: f940203b ldr x27, [x1, #64] u16 rev[] = L"0.0.0"; 64: aa1303e0 mov x0, x19 struct efi_boot_services *boottime = systable->boottime; 68: f940303a ldr x26, [x1, #96] u16 rev[] = L"0.0.0"; 6c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 70: 91000021 add x1, x1, #0x0 74: 94000000 bl 0 <memcpy> /* UEFI requires CR LF */ con_out->output_string(con_out, L"Hello, world!\r\n"); 78: f9400762 ldr x2, [x27, #8] 7c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 80: aa1b03e0 mov x0, x27 84: 91000021 add x1, x1, #0x0 88: d63f0040 blr x2 Regards Heinrich _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot