To view parent comment, click here.
To read all comments associated with this story, please click here.
Well, it can be considered a secret, since what Apple calls "EFI" only remotely complies with the EFI and UEFI specs and keeps doing weird undocumented stuff (such as overwriting kernels after boot) all the time.
Here are some examples :
http://mjg59.livejournal.com/132477.html
http://mjg59.dreamwidth.org/12037.html
Neolander,
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.
Here are some examples :
http://mjg59.livejournal.com/132477.html
http://mjg59.dreamwidth.org/12037.html
To be fair, if you follow Matthew's posts, it's clear that *nobody* remotely complies with the standards.





Member since:
2009-08-18
It isn't kept secret, they simply don't support it.