In article <calokogw8hwfkw2ksthlyokqyexnnifgo2yqxfyasnqukb6o...@mail.gmail.com>, Sheda <[email protected]> wrote: >On Fri, Jan 22, 2016 at 1:46 AM, Christos Zoulas <[email protected]> wrote: >> In article >> <calokogxnvqkf8y_zddbch4kjxqkztarffoucyetj_j4olfh...@mail.gmail.com>, >> Sheda <[email protected]> wrote: >>>The patch (grub-knetbsd-efi-systbl.patch) I submitted to the GRUB team >>>in 2014 was commited. So it would be great to integrate its >>>NetBSD-counterpart (efi.patch) or at least discuss it. >>>The problem this patches solve consist in booting NetBSD/amd64 on an >>>EFI machine via GRUB because, AFAIK, there's no alternative. >> >> You mean this patch: >> https://mail-index.netbsd.org/tech-kern/2014/05/22/msg017119.html > >Yes, the NetBSD-part of this patch as the GRUB-part was committed. > >> How can we test this? > >You should attempt to boot NetBSD with an EFI with no Compatibility >Support Module (CSM) enabled. Doing that should result in the kernel >being unable to locate the ACPI tables. AFAIK, that's where GRUB >become the only option: install GRUB with EFI support and attempt to >boot NetBSD using the knetbsd command. The patch should do 2 things: >- make the kernel support a new parameter, BTINFO_EFI, that is >expected to be the physical address of the EFI System Table; >- and use this information to locate the ACPI tables.
I am inclined to just commit this until we get native bootloader EFI support. What do others think? christos
