- 64BIT CLOVER EFI FOR FLASH DRIVE MAC OS
- 64BIT CLOVER EFI FOR FLASH DRIVE WINDOWS 8
- 64BIT CLOVER EFI FOR FLASH DRIVE WINDOWS
But yeah, for quick testing especially, a non-invasive option would be better. It's a way more invasive modification but it would permanently turn them into modern systems. This would allow such systems to boot the 64-bit versions of most common operating systems without requiring any hacks or patches.Ĭustom firmware based on coreboot+edk2 might be a good alternative for making these devices more useful. 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). 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. I didn't mean restoring the 32bit abilities of Clover. Anyway this is necrophilia and if someone want to restore 32bit abilities then welcome to be a developer Sorry for the confusion, but that was not what I meant. Currently Clover has legacy boot mode and some years ago it could be 32-bit mode supporting 32-bit UEFI Runtime Functions. A (currently still open) issue about properly supporting (U)EFI Mixed Mode in systemd.
64BIT CLOVER EFI FOR FLASH DRIVE MAC OS
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.Some other related projects that might be useful to mention here: I'm interested in hearing what obstacles there would be towards such a solution. 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. Sure, with 2GB RAM, their functionality would still be limited, but there are plenty of applications that these things could still be used for.
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. 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? 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). Unfortunately, a CSM was not included in these implementations, so that option is not available.
64BIT CLOVER EFI FOR FLASH DRIVE WINDOWS
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.
(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. Some Linux distros, particularly Ubuntu and Fedora, support this out-of-the-box in their regular 64-bit installation media. However, the Linux kernel eventually gained support for "mixed mode UEFI", allowing a 64-bit Linux kernel to boot from a 32-bit UEFI.
64BIT CLOVER EFI FOR FLASH DRIVE WINDOWS 8
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 decision also reeks a bit of "planned obsolescence" to me, but I digress.) 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. 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. 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. Just skip those if you're aware of the problem.) (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. I know what I'm proposing here isn't trivial, but please bear with me.
0 kommentar(er)
