When I got my Mac Mini, one of the very first things I did was to test the Debian build of rEFIt on the machine, given the EFI firmware is x64 on the newer machines whereas it’s ia32 on my MacBookPro; it was the very first time I could test the x64 build.
And the results weren’t good: some images couldn’t be loaded, and it all seemed to be random.
Disabling optimization in both GNU EFI and rEFIt for the x64 builds helped somewhat, at least it made rEFIt reliable enough to be usable.
Now, with this new release, I started getting error messages, requiring a key press before the menu would be displayed. It’s annoying but it’s also very helpful as I now had an error message to work with, and even if the error message wasn’t reliable, it would still point me to some part of the code. The message was: Invalid argument.
On x64, the use of a call wrapper is mandatory because the EFI x64 calling convention doesn’t match the calling convention of the ELF executables we’re building and later disguising as EFI executables. The call wrapper has always been the prime suspect in this issue, it’d be an obvious candidate for anyone looking at this issue.
Today, digging into the issue with some new data, I realized what the problem was: when using the call wrapper, all arguments need to be of the UINT64 type. That’s the type the call wrapper uses when extracting the arguments from its va_list.
Introduce some more macros on top of the call wrapper, build, test: voila, it’s fixed! That was tricky one.
Let’s sum it up for the search engines: all the arguments to the EFI interface called through uefi_call_wrapper() in GNU EFI need to be cast to UINT64.
rEFIt 0.14-1, available in unstable in a couple hours.
Next, I’ll see if I can reenable optimization in both GNU EFI and rEFIt.