Thanks Dave. On Fri, Jan 13, 2017 at 3:03 AM, Dave Young <dyoung@xxxxxxxxxx> wrote: > On 01/12/17 at 04:20pm, Ard Biesheuvel wrote: >> On 12 January 2017 at 09:41, Dave Young <dyoung@xxxxxxxxxx> wrote: >> > Before invoking the arch specific handler, efi_mem_reserve() reserves >> > the given memory region through memblock. >> > >> > efi_bgrt_init will call efi_mem_reserve after mm_init(), at that time >> > memblock is dead and it should not be used any more. >> > >> > efi bgrt code depend on acpi intialization to get the bgrt acpi table, >> > moving bgrt parsing to acpi early boot code can make sure efi_mem_reserve >> > in efi bgrt code still use memblock safely. >> > >> > Signed-off-by: Dave Young <dyoung@xxxxxxxxxx> >> >> I know this is probably out of scope for you, but since we're moving >> things around, any chance we could do so in a manner that will enable >> BGRT support for arm64/ACPI? Happy to test/collaborate on this. >> > > I'm happy to do so, Bhupesh Sharma <bhsharma@xxxxxxxxxx> said he had > some investigation on that already, I would like to ask him to help on that. > > Already cced him.. Hi Ard, I have started working on an implementation where most of the BGRT code which exists inside 'arch/x86/platform/efi-bgrt.c' can be reused for ARM/ARM64. I am testing a RFC approach for the same using Qemu for AARCH64. I have sent out a patch to enable BGRT support in ArmVirtPkg (see [1]) I have one question regarding the placement of the early bgrt handling code so that it can be reused on both arm/arm64 and x86: - Should I consider moving the current code from arch/x86/platform/efi-bgrt.c to outside arch/x86 so that it can be used by both the ARCHs or should I reuse the existing x86 stuff in a ARM specific way - no mem_remap for e.g. in a find inside arch/arm - say efi-arm-bgrt.c Suggestions? [1] https://lists.01.org/pipermail/edk2-devel/2017-January/006588.html Regards, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
