The MinnowBoard is an Intel Atom SoC based board similar to Raspberry Pi or BeagleBoard. It ships with [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome Tianocore UDK] based 32-bit UEFI-only firmware which does not contain CSM support. See below links for more info.

+

The MinnowBoard is an Intel Atom SoC based board similar to Raspberry Pi or BeagleBoard. It ships with [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome Tianocore UDK] based 32-bit UEFI-only firmware which does not contain CSM support (no Legacy BIOS boot). The embedded Atom processor is supports only 32-bit, hence it is not possible to replace the 32-bit UEFI in the board with 64-bit (x86_64) UEFI. See below links for more info.

Observations

UEFI Secure Boot support is present in firmware, but I have currently disabled it. System came pre-installed with Windows 7 Pro x64 in BIOS-MBR mode, with BIOS version 1.14 (which did not include UEFI Secure Boot).

After BIOS update, all boot entries got erased and I had to recreate them using efibootmgr.

No issues with efibootmgr for creating entries for rEFInd and GRUB 2.x . But unable to create direct EFISTUB entries as described at UEFI_Bootloaders#Using_efibootmgr_entry (echo'ed kernel parameters are truncated by efibootmgr).

Currently using rEFInd (textonly mode) as main boot manager (1st in boot menu) with grub-efi-x86_64 (2nd in boot menu) and grub-bios installed as fallback. rEFInd is first in boot menu (installed at <UEFISYS>/EFI/refind/refindx64.efi). No need for /EFI/Microsoft/Boot/bootmgfw.efi hack. Dual-booting Windows 8 Pro x64 UEFI-GPT (chainloaded from rEFInd/GRUB) works without any issues. Windows boot files are stored in same UEFISYS partition.

Both UEFI Shell v2 and v1 work, launched from rEFInd or grub-efi-x86_64. No option in the firmware setup/menu to directly launch the shell.

grub-bios works if the firmware is changed to boot "Legacy only" without any boot/active flag in 0xEE Protective MBR partition entry.

Gummiboot v8 works fine without any errors.

Using only PARTUUID in /etc/fstab and in bootloader config files.

Important Info

I didn't use Archiso or Archboot to install the system. I transferred the Arch installation from my old Sony Vaio laptop to my new Thinkpad E430 using an external USB HDD and rsync from within SystemRescueCD, after manually creating the partitions using GParted, and then manually setup fstab and rEFInd. After that I rebooted into Arch and installed grub-efi-x86_64 and grub-bios.

From WonderWoofy

On an E430-3254(CTO) I had the same issues as the.ridikulus.rat with efibootmgr and truncated kerl command line parameters. This usually lead to the inability of the kernel to find the initramfs. What I ended up doing is putting the kernel and intramfs in the root of the ESP, and from there the efibootmgr entries worked nicely. This does lead to an ESP that is not organized in the recommended way though.

Also, I did actually install via Archboot, and all worked fine. I have actually installed twice on this machine, once to a Momentus XT and once to a Samsung 830. The first time I used a CD, and therefore selected the "UEFI First" preference in the bios. This supposedly will try UEFI (\EFI\boot\bootx64.efi) first, and if that fails it will look to the MBR. Unfortunately, it did not honor this setting for the optical drive, and I had to turn off legacy bios mode entirely to get it to boot in UEFI from the CD. Interestingly, this "UEFI First" setting works just fine for interal drives. USB flash drives are a whole different story though, and more information can be found here.

System76 Galago UltraPro

System Info

System76 Galago UltraPro (Clevo W740SU)

intel core i7 4750HQ 2.0GHz

intel HM87 Chipset

Original firmware version unknown, but from American Megatrends Inc.

Boot in UEFI mode only possible by starting an UEFI shell via the BIOS setup ($esp/shellx64.efi)

UEFI menu entries could be created by using efibootmgr, but without them being shown in the bootup menu

MinnowBoard

The MinnowBoard is an Intel Atom SoC based board similar to Raspberry Pi or BeagleBoard. It ships with Tianocore UDK based 32-bit UEFI-only firmware which does not contain CSM support (no Legacy BIOS boot). The embedded Atom processor is supports only 32-bit, hence it is not possible to replace the 32-bit UEFI in the board with 64-bit (x86_64) UEFI. See below links for more info.

Intel Atom SoC Clover Trail

Intel Atom SoC Clover Trail processors are 32-bit only, hence they contain only 32-bit UEFI firmware. These systems can be booted only using a 32-bit UEFI bootable USB, which is not provided by default in Archiso (official install iso) and Archboot. Apart from this, Intel does not seem to have released the related Graphics and Power-saving code for Linux. Hence these systems may not work reliably with Linux. Officially Intel has stated that Linux will not be supported in Clover Trail tablets.

Intel Atom SoC Bay Trail

Intel Atom SoC Bay Trail processors actually support 64-bit, but these tablets ship with only Windows 8/8.1 32-bit (not 64-bit) because of a feature called Connected Standby which is mandated by Microsoft to be enabled, but currently supported only by Windows 8/8.1 32-bit version (not 64-bit, as of October 2013). Connected Standby requirements (by Microsoft) include tablets to support only UEFI boot (hence no BIOS CSM) and UEFI bitness to match the OS bitness (hence 32-bit UEFI for sake of Win 8/8.1 32-bit). With only 32-bit UEFI and lack of BIOS compatibility, even Windows XP/Vista/7 32-bit (no UEFI support) and 64-bit (cannot boot in 32-bit UEFI) cannot be installed in these systems. These systems are truly locked to Windows 8/8.1 32-bit (UEFI mode).

In these systems it should (theoretically) be possible to install 64-bit Linux provided the kernel is instructed to not access EFI runtime code using the noefi kernel parameter, due to the kernel/UEFI bitness mismatch. Similar to Clover Trail, Intel does not seem to have released Graphics and Power-saving code for Linux for Bay Trail as well.