Feature request: chainloading a 64-bit (x64_64) UEFI from a 32-bit (x86/ia32) UEFI

[volkertb]

I know what I'm proposing here isn't trivial, but please bear with me. (The first three following paragraphs are to provide context for those reading this who are not familiar with the phenomenon of 64-bit Intel systems shipping with 32-bit UEFIs. Just skip those if you're aware of the problem.)

So some years back, Intel released Bay Trail and Cherry Trail SoCs (used in small and low power form factors such as the Intel Compute Stick and some x86 tablets), and supplied OEMs with a 32-bit UEFI for them, even though the CPUs were perfectly capable of running 64-bit code. The reasoning behind this was that it would be more optimal to have them boot 32-bit versions of Windows, since such SoCs didn't ship with more than 2GB of RAM anyway, and running 64-bit versions of Windows would take up more RAM. This was of course short-sighted, because it didn't take into account the limited remaining longevity of 32-bit x86 operating systems and the lack of further long-term application support for that architecture. (This decision also reeks a bit of "planned obsolescence" to me, but I digress.)

Indeed, Windows 8 and 10 on UEFI require a 32-bit UEFI for the 32-bit variants of the OS, and a 64-bit UEFI for the 64-bit variants. This cannot be mixed. However, the Linux kernel eventually gained support for "mixed mode UEFI", allowing a 64-bit Linux kernel to boot from a 32-bit UEFI. Some Linux distros, particularly Ubuntu and Fedora, support this out-of-the-box in their regular 64-bit installation media. Chrome OS Flex supports this as well. (I've tested this on a Bay Trail device with a 32-bit UEFI and it works, in 64-bit mode.) Notably however, Clear Linux* OS, developed and funded by Intel, refuses to support this mixed mode, even though Intel caused this mess in the first place.

Now, had the 32-bit UEFIs in these SoCs included a CSM to allow legacy BIOS compatibility, Clover could have been used as a workaround to boot 64-bit versions of Windows and Clear* Linux from such systems. Unfortunately, a CSM was not included in these implementations, so that option is not available.

In addition to these Intel SoCs, there were also some older generation Apple Mac products that had basically the same conundrum (a 64-bit capable CPU limited by a 32-bit EFI firmware).

Which brings me to this feature request: would it be feasible to port Clover to a 32-bit UEFI boot payload that launches its CloverEFI UEFI firmware emulation in 64-bit mode? So in effect chainloading (or bootstrapping) a 64-bit UEFI implementation from a 32-bit UEFI? The 64-bit Linux kernel is capable of booting into 64-bit mode from a 32-bit UEFI, using the aforementioned mixed mode support, so why couldn't Clover be made to use the same mechanism?

This would "liberate" such 64-bit-capable platforms that would otherwise be stuck in 32-bit land, and extend their usefulness instead of these things ending up on a landfill. Sure, with 2GB RAM, their functionality would still be limited, but there are plenty of applications that these things could still be used for. The 32-bit x86 platform is basically end-of-life, and more and more applications are no longer being released for 32-bit, even though they don't require more than 2GB of RAM to work.

I'm interested in hearing what obstacles there would be towards such a solution.

Thank you for your consideration.

Some other related projects that might be useful to mention here:

• macosxbootloader, boot loader for older 64-bit Macs with 32-bit EFI firmware, to be able to boot newer 64-bit versions of Mac OS X, using the same mixed mode (thunking) mechanism
• A (currently still open) issue about properly supporting (U)EFI Mixed Mode in systemd

[SergeySlice]

Yes, it is possible. Currently Clover has legacy boot mode and some years ago it could be 32-bit mode supporting 32-bit UEFI Runtime Functions.
Anyway this is necrophilia and if someone want to restore 32bit abilities then welcome to be a developer yourself.

[valpackett]

Custom firmware based on coreboot+edk2 might be a good alternative for making these devices more useful. It's a way more invasive modification but it would permanently turn them into modern systems. But yeah, for quick testing especially, a non-invasive option would be better.

[volkertb]

Yes, it is possible. Currently Clover has legacy boot mode and some years ago it could be 32-bit mode supporting 32-bit UEFI Runtime Functions. Anyway this is necrophilia and if someone want to restore 32bit abilities then welcome to be a developer yourself.

@SergeySlice Sorry for the confusion, but that was not what I meant. I didn't mean restoring the 32bit abilities of Clover. I am asking for a 64-bit version of Clover that could be bootstrapped from a 32-bit UEFI on otherwise 64-bit systems, such as older Macs and some Intel SoCs such as Bay Trail. So basically a 64-bit UEFI being chain-loaded from the 32-bit UEFI that those systems were shipped with (and which lacks a CSM, making it impossible for Clover to be booted on those systems in Legacy BIOS mode). This would allow such systems to boot the 64-bit versions of most common operating systems without requiring any hacks or patches.

Custom firmware based on coreboot+edk2 might be a good alternative for making these devices more useful. It's a way more invasive modification but it would permanently turn them into modern systems. But yeah, for quick testing especially, a non-invasive option would be better.

I agree, having Coreboot ported to such systems would be better still, and someone inquired about that in this thread in the Intel community forums, but that appears to have gone no-where, unfortunately.

[SergeySlice]

If there is no CSM then it is impossible to run legacy Clover which can boot other OSes.
If there is 32bit UEFI then you can start Clover-32bit in UEFI mode. It is impossible to run Clover-64 with 32bit UEFI because Clover uses runtime functions like gBS->LoadImage() which is 32 bits here.
The only way is to use CSM.

[volkertb]

The Linux kernel has a config option called CONFIG_EFI_MIXED. When compiled with this option enabled, the 64-bit kernel image is able to be bootstrapped from a 32-bit UEFI. (At the moment, it does require Grub for that, but still, it's possible.) The kernel switches to 64-bit mode and whenever it needs to call the 32-bit UEFI, it does so through a thunking layer.

Why not use the same mechanism for a 64-bit Clover version? Let it load its own 64-bit drivers and take over things natively as much as possible, and defer to the underlying 32-bit UEFI through such a thunking layer for everything else.

I'm not saying it's trivial, but I still haven't heard any arguments as to why this would be impossible. I do understand that Clover is BSD-licensed, so copying GPL'ed Linux code might not be desirable, but the same principle could be reimplemented in clean code, or otherwise ported in a separate optional module, which would leave the rest of the Clover source code BSD-licensed, right?

As for having to initialize the graphics subsystem, apparently many non-CSM UEFI systems still have VGA BIOSes in ROM that could still be loaded, so the graphics could be accessed through int 10h, as in legacy systems. See @tkchia's project for more info on that: https://github.com/tkchia/biefircate

[SergeySlice]

Clover 32bit can boot macOS in 64bit mode. As well Linux+Grub itself know what to do. Windows too.

[volkertb]

Okay, so there is a way for 64-bit macOS to boot from a 32-bit UEFI.

But "Windows too"? Only Windows ia32, which is a legacy architecture at this point. Windows x64 still requires either 64-bit UEFI or legacy BIOS (CSM). And there are some Linux distros, notably Clear Linux*, that don't support Grub and also require a 64-bit UEFI.

There is a use case for this.

[rafi16jan]

Okay, so there is a way for 64-bit macOS to boot from a 32-bit UEFI.

But "Windows too"? Only Windows ia32, which is a legacy architecture at this point. Windows x64 still requires either 64-bit UEFI or legacy BIOS (CSM). And there are some Linux distros, notably Clear Linux*, that don't support Grub and also require a 64-bit UEFI.

There is a use case for this.

@SergeySlice does clover support booting legacy boot OS (Windows 10 x64 legacy mode for example) from IA32 EFI?

[NeoLizzard]

I would love to see it working too. This was pretty much my last night, trying to make my baytrail schenker element tablet go x32 uefi -> x64 uefi. I managed so far to force feed the the disk by using dism for putting Windows 11 x64 on the drive (yeah... madnass...) and then went with all loading hacks that I can come up with. However the limitation here was hit in my case when I hit winload.exe (since the call was still beeing made by ia32). I also tried to chainload from bootia32.efi into bootx64.efi - with quiet no success... My idea was to try to use grub with a grub config to do it - But so far no progress that is worth mention. It was just a couple of hours of try and error. Check easy2boot as a base, since they support a huge amount of boot processes for loading their iso stuff. Maybe you find something that I have overlooked. https://easy2boot.xyz/ (and yes... page look like shit... but the tool is good...). There is also a part about this topic mentioned on the dev. page of easy2boot (https://easy2boot.xyz/agfm/things-to-know-about-uefi/)

Beginning at: ". There are two types of UEFI Intel x86 firmware, 32-bit or 64-bit. We need to know what type the target system has. Check what OS was originally shipped on the system. If it was a Windows 64-bit OS, then you have 64-bit UEFI firmware. If it was shipped with a 32-bit Windows OS, then you have 32-bit UEFI firmware. Note that the CPU inside the target system may be 64-bit, but the UEFI firmware may be 32-bit! Systems with limited internal storage tend to have 32-bit UEFI firmware because 32-bit OS’s require less disk space than 64-bit OS’s..."

[Viking8]

I've been banging my head against a wall trying to get 64 bit Linux Mint to boot from internal storage on my Dell Venue 10 Pro 5055 tablet without success. I did try Debian 12 the day it was released and it actually booted, but man was it slow. The LM 21.1 live USB ran faster. Some things in Debian didn't work properly, but everything worked in Mint. At one point I thought clover might be my saviour, but it didn't work either, so I'd love to see clover adopt this function as well.

[rafi16jan]

I've been banging my head against a wall trying to get 64 bit Linux Mint to boot from internal storage on my Dell Venue 10 Pro 5055 tablet without success. I did try Debian 12 the day it was released and it actually booted, but man was it slow. The LM 21.1 live USB ran faster. Some things in Debian didn't work properly, but everything worked in Mint. At one point I thought clover might be my saviour, but it didn't work either, so I'd love to see clover adopt this function as well.

If LM 21.1 live usb will work, then your best bet is using casper-rw so your livecd partition will persist

[alcatraz-zz]

This thread was a great read. I'm also trying to boot win64 on ia32 efi.

[volkertb]

(EDIT: the following post was in response to a now-deleted comment)

There's no need to be so rude. 😕 And feature requests are also opened as issues. And then they can be assigned a separate enhancement label. But I don't have the rights to do that myself.

I've used GitHub enough over the years to understand how this works.

[superluig164]

Hopefully this isn't too much of a necro, but I have been looking into ways to get Windows x64 booting on these tablets for quite a long time, and if this ever gets implemented or even partially implemented it might be the holy grail. I'm not a developer unfortunately, but I'd be happy to help conduct testing or any kind of help I can give to make something like this work. Unfortunately it seems like the issue is compounded by Ubuntu and ChromeOS supporting the setup natively already, leading to barely anyone seeing the point in putting in the work to hack around something like this. Either way, I hope it goes somewhere, just writing to add my +1 I suppose.