The ACPI tables (/sys/firmware/acpi/tables/UEFI) should (are) always be there (depending on the board), regardless of the question if the system has been booted via BIOS/ legacy CSM or UEFI.
Okay, you're booting via UEFI and have you installed the OpenWrt EFI image too?
Btw: You both have an v01 ALASKA A M I BIOS it seems.
However, I'm running out of ideas for now 
Yes to both (openwrt-x86-64-generic-squashfs-combined-efi.img.gz).
I only see the "traditional" one on my UEFI-booting Celeron N5105 with SNAPSHOT from the usual openwrt-x86-64-generic-squashfs-combined-efi.img.gz:
$ ll /sys/firmware/efi
drwxr-xr-x 5 root root 0 Mar 20 07:11 ./
drwxr-xr-x 6 root root 0 Mar 20 07:11 ../
-r--r--r-- 1 root root 4096 Mar 26 11:17 config_table
dr-xr-xr-x 2 root root 0 Mar 20 07:11 efivars/
drwxr-xr-x 3 root root 0 Mar 26 11:17 esrt/
-r--r--r-- 1 root root 4096 Mar 26 11:17 fw_platform_size
-r--r--r-- 1 root root 4096 Mar 26 11:17 fw_vendor
-r--r--r-- 1 root root 4096 Mar 26 11:17 runtime
drwxr-xr-x 11 root root 0 Mar 26 11:17 runtime-map/
-r-------- 1 root root 4096 Mar 26 11:17 systab
$ ll /sys/firmware/acpi/tables/UEFI
ls: /sys/firmware/acpi/tables/UEFI: No such file or directory
Edit:
[ 0.000000] efi: EFI v2.70 by American Megatrends
[ 0.000000] efi: ACPI=0x747cd000 ACPI 2.0=0x747cd014 TPMFinalLog=0x747d0000 SMBIOS=0x74c7b000 SMBIOS 3.0=0x74c7a000 MEMATTR=0x6effa018 ESRT=0x70d3e898
ACPI tables do not indicate runtime state. Disk partitions or file systems do not indicate runtime state. It's obviously possible to boot systems and images with UEFI support in other ways,
/sys/firmware/efi/ directory existence should be a reliable test. It is always created along with at least the
/sys/firmware/efi/fw_platform_size
attribute (there are other attributes too on x86, but those depend on the platform).
The directory exists if
efi_enabled(EFI_BOOT)
is true, except it runtime services is supported but we fail to create a workqueue for it: Ref:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/efi.c#n382
Not exactly sure what will happen if workqueue creation fails. But if that happens then you should at least see an error message in the kernel log. I don't think this could be a common problem on all OpenWrt systems.
I find it way more likely that those of you who don't see the /sys/firmware/efi directory are actually booting the traditional BIOS way without being aware of that.
But I'm not an expert, and even they are sometimes wrong too 
2 Likes
Not being as knowledgable as @bmork I did assume an incompatibility between the boards firmware and the kernel 
If I change the firmware type for the VM from 'efi' to 'bios' the EFI image still boots just fine. But there are not 'EFI' entries in dmesg anymore and of course the /sys/firmware/efi folder is missing.
Booting in 'bios' mode fails if I let fdisk fix the partition order. But boots fine with the fixed partition order if set to 'efi'.
That would be one way to verify the booting mode, still no fixed of course.
@NC1 do you have the option of installing a Linux distro like Ubuntu or Arch Linux on it to see if you encounter the same issue there? If it works with them then it's an issue that was fixed upstream. If no it's either not fixed or there's an issue with the firmware and its UEFI compatibility.
Maybe simply booting from a live USB would be good enough? Beats doing a full installation for convenience...
1 Like
Just a note:
I dusted off my rusty/trusty Sophos SG105r3 (with an E3930 cpu), set the BIOS boot to UEFI and started latest stable OpenWrt from an USB stick (EFI combined Ext4 image). In my instance /sys/firmware/efi does exist.
When I switch back to legacy boot OpenWrt still boots fine, /sys/firmware/efi is missing but there are dmsg entries for EFI (so existence of these entries doesn't help)
~# dmesg | fgrep -i efi
[ 0.012766] ACPI: UEFI 0x0000000079E6EEE0 000042 (v01 ALASKA A M I 00000000 00000000)
[ 0.012858] ACPI: Reserving UEFI table memory at [mem 0x79e6eee0-0x79e6ef21]
[ 0.026188] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
Using dmidecode the following info are available about the BIOS:
dmidecode BIOS info
BIOS Information
Vendor: American Megatrends Inc.
Version: 5.12 (Z131-014)
Release Date: 01/05/2018
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 5120 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 5.12
2 Likes
That's what I thought might be happening in my case. Thank you for posting this!
As to searching dmesg output for instances of efi, I think it detects the presence of UEFI-capable hardware, rather than the nature of image used. On two devices that I have right now running off BIOS images (one ext4, the other SquashFS), the output is almost identical to what you posted:
~# dmesg | fgrep -i efi
[ 0.010069] ACPI: UEFI 0x00000000B99D26F8 000042 (v01 ALASKA A M I 00000000 00000000)
[ 0.010129] ACPI: Reserving UEFI table memory at [mem 0xb99d26f8-0xb99d2739]
[ 0.033682] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
To repeat, I think what this tells us is that the BIOS chip is UEFI-capable...
1 Like
Having looked as some code for tools that work with EFI vars in Linux, they all depend on the existence of /sys/firmware/efi (C based one, not shell). Right now I'd say if that directory doesn't exist, you're not booted in EFI mode.
2 Likes