Linked by moondevil on Wed 11th Jul 2012 22:49 UTC
Mac OS X Ars Technica is reporting that certain 64bit Mac models won't be able to run Mountain Lion. The problem is the graphic card drivers; these are still 32bit, and Apple is unwilling to update them to 64bit. A 64bit kernel can't load 32bit drivers, so that's that. Apple has a list of supported models on their Mountain Lion upgrade page, so you can easily check if your computer is capable of running Mountain Lion.
Thread beginning with comment 526533
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: No biggie
by Alfman on Thu 12th Jul 2012 14:41 UTC in reply to "RE[3]: No biggie"
Member since:


Your links were a good read. The second one about the MAC boot process was eye-opening, wow are there a lot of dependencies. I'm not sure why apple would stray from a vanilla EFI implementation.

One parenthesised comment came up though and I think it's particularly relevant to a discussion of running 32/64bit OSes together.

"So then we have runtime services. EFI is, depending on how you want to look at it, either saner or much less sane than traditional BIOS access. The firmware gives you a bunch of function pointers and you then simply call them with native calling convention (this, incidentally, is why it's pretty much impossible to run a 32-bit OS on 64-bit EFI, or a 64-bit OS on a 64-bit system that happens to have 32-bit EFI)."

In theory, it shouldn't be too difficult to build a shim between 32bit and 64bit calling conventions. It might not be the most efficient solution, but I see no reason this shim couldn't be generated automatically from EFI function call prototypes.

A 64bit EFI should be able to handle zero padded 32bit OS pointers. The main question I have is whether the EFI data structures themselves change between 32bit and 64bit interfaces, because if they do then that rules out this simple trampoline approach.

Reply Parent Score: 4