Yosemite support for old MacPro’s

If you happen to own one of these ‘good old’ (solid) MacPro’s then you most definitely know the macosxbootloader project, developed by Tiano in 2013. Unfortunately, it lacks support for Yosemite, and with the first GM candidate now being tested by (registered) Mac developers… its boot.efi replacement is starting to annoy people, who are eagerly awaiting for someone to fix this. And because nobody else stepped in before me, Peter Holbrook asked for a little help. Sure. No problem!

The first problem was to find someone that could compile the source code, since I don’t use Microsoft Windows, and that hurdle is already taken. I now have remote access to a MS box with all dev tools installed on it, and it appears to work. Pretty cool.

Now the big question is; Can you deliver Pike? Sure we can. And note that I used “we” here, because I need your help just as much as (some of) you need my help because I do not have an old MacPro to play with. So please, let us try to solve this as friends, sharing the same passion for old stuff. Lol.

Anyway. The first couple of changes went in already, and all that is missing to actually boot Yosemite on your good old MacPro is the missing “random-seed” property (see TODO file). So how do we attack this?

Simple. Open BootArgs.cpp and look for BlInitializeBootArgs. Add the seedBuffer declaration and call to DevTreeAddProperty () above the line with:

*bootArgsP = bootArgs;

You may need to change it a little, but I am past my bed time already so this exercise is yours my friends 😉

After this you compile and replace boot.efi with the new file. Then try to boot with -f because that will skip kernel cache. You need this due to the lacking LZVN decompression, but that can be added later on. This step is to see if the reboot is gone. That and finding the kernel are key tests now.

If it can’t find the kernel, then I made a mistake somewhere. In that case be smart and use the kernel boot argument, to load the kernel of your choice.

Gaap. I really, really need to get some sleep now. Our son will wake up for food in the middle of the night so.. have fun guys and gals. See you on the other side of the moon!


Someone e-mailed me about setting up a 90-day trial version of Visual Studio and NASM on his 2006 MacPro, because he ran into this error after trying to build the source code:

Error 1 error MSB6006: "cmd.exe" exited with code 9009.

Right. We got the same error when we forgot to add the path to the NASM executable. We fixed it and after that everything was fine.


New experimental patches have been committed, a few minutes ago, but I don’t know if they will work (compiles fine) because I don’t have an old MacPro.


36 thoughts on “Yosemite support for old MacPro’s

  1. Although I can’t presently test any boot.efi developments that require booting into Yosemite, yesterday I installed Visual Studio Professional 2013 and Nasm for DOS in a Windows 8.1 virtual machine under Fusion 7. Unfortunately, I ended up with roughly 100 Mb of free space in my virtual disk. When I was resizing, I found that at least one user had successfully compiled boot.efi both from Tiamo’s original repository and the one including your patches, so I didn’t continue. Am I right in assuming the project is now proceeding as it should and you don’t need any more people for compiling your code?

    • Hi Peter,

      Having access to a remote development box will certainly help me to get it compiled, but since I don’t have a good old MacPro… I still need people for testing/verifying patches. Some of which with Visual Studio/NASM installed, because then they can also make quick-n-dirty changes, run tests, confirm if it works, before I commit them into my Github repository.

      Also. It is fun when other people come up with patches. Even for LZVN, for which we have working source code already, because for me it is no challenge anymore. Getting people inspired to do what they never did before, or a long time ago, is however still fun.


      • OK. I’ll co-compile as time allows, along with other enthusiasts, in case I can somehow contribute something.

  2. I’ve tried now the new experimental patches from Oct 3rd. While compiling I got a lot of warnings for the MiscUtils.cpp ‘Converting from UINT64 to UINTN, data loss possible’. I get no compiled Boot.efi. Tiamo’s source compiles still flawless.

      • No, the platform is still Win32. As I compiled Tiamo’s source for the 1st time I chose x64 and this was wrong and the Boot.efi was too large and doesn’t boot.

        Apart from that, with x64 I get for the new patches the error MiscUtils.cpp ‘UINTN cannot be converted into UINT8 *’.

  3. same result as atvusr. I then replaced “MiscUtils.cpp” with the one from the Tiamo original and now I’m getting errors LoadKernel.cpp error BlDecompressLZSS identifier not found and LoadKernel.cpp error BlDecompressLZVN identifier not found. also Console.cpp error BlDecompressLZSS identifier not found.

    • We are patching files to get it to work with the 64-bit Yosemite kernel and kernel cache, so that is to be expected i.e. you should not mix the unpatched files with patched files. For example. There are now two decompress functions. One for LZSS and one for the new LZVN. This also means that I had to rename stuff.

      • I’m just trying to get boot.efi to be built. to be honest, I have no clue at all about what I’m doing here. but it’s fun anyway… the compile is successful if I use tiamo’s Console.cpp & LoadKernel.cpp & MiscUtils.cpp.

      • okay, here’s what I did: I replaced Console.cpp & LoadKernel.cpp & MiscUtils.cpp with tiamo’s versions and then compiled successfully. placed boot.efi on a HD with a freshly installed 10.10. I also deleted the kernel cache. I then plugged the disk into my MacPro2,1 (flashed from a MacPro1,1). and booted OS X Yosemite! it boots in verbose mode.

      • You replaced Console.cpp with the original one, and yet it still finds the kernel? How does that work? Oh I see, the other patched files, but Console.cpp should work. Correct?

        More importantly. You compiled the 32-bit target? What size is boot.efi?

      • as if I had a clue, haha. I don’t know why it finds the kernel. maybe this is why the system seems to hesitate for a few seconds before booting. also it looks like the kernel cache works. at least a fresh kernelcache is built during reboot.

      • The kernel cache will be rebuilt, yes, but you cannot use a LZVN compressed kernel cache. Not without the patched files. You may use the -f (skip kernel cache) boot argument, or you may have changed the preferred cache to LZSS in: /usr/standalone/bootcaches.plist because otherwise it would be impossible.

        Anyway. It is good to see that we are making progress, but please use the patched copy of Console.cpp and tell me if your boot screen is black or grey. Then I know what to do next.

  4. I can’t say I have it working – i haven’t yet found a compiled EFI file to play around with. My Mac Pro is also at work 😦

    But @pikerAlpha HUGE KUDOS and thanks for taking this a huge step forward!

  5. Compiling with x64 was now flawless with the fixed typo, but it doesn’t boot on my MBP2,2 with EFI32. Still the Converting-error in Win32 mode for the MiscUtils.cpp. 😦

    • Right. It is booting up in black mode with the white Apple logo. Just like I expected, but no kernel cache. Seriously. The minute you see it booting up with the new decompression… you’ll gonna be amazed.

  6. Pingback: Old MacPro’s and Yosemite | Pike's Universum

  7. Wonderful job pike and mike! 🙂
    Works like a charm. Changed compression to lzss and black mode appears only for a fraction of a second. What is needed to implement lzvn now? My skills in programming are less than poor, but I’m willing to help if I can.

  8. Hello, Pike. For some reason, VS wouldn’t recognise the presence of nasm anywhere in the path. First I tried nasm for DOS and I placed it in C:\NASM. When that didn’t work (as far as building went), I added Nasm for Windows, and I placed it in C:\Porgram Files\Nasm. The path ended in C:\Nasm;”C:\Program Files\NASM”, but that wouldn’t work either. I finally deleted both NASM instances and reinstalled the Windows version in C:\Nasm, leaving C:\NASM at the end of the path (Hennesie provided valuable advice about all this path business).

    Then I ran the desktop alias to make sure NASM was reachable and, indeed, it was. After all this, I tried with your project the way it was last night and the build didn’t succeed because there was some undeclared variable. Finally, after downloading the project as it is now, the build succeeded. I find it unexpected, though, that “my” boot.efi is exactly 65,536 bytes long. Perhaps I’m doing something wrong?

    Edit: I was looking at the wrong file. The true size of “my” boot.efi is 465.408 bytes. That’s more like it!

  9. Pingback: Les premiers Mac Pro auront bientôt droit à Yosemite - PC Help

  10. I know there are a lot of discussions out there on compatibles GPUs. At the moment i have a quadro FX 4500 which is, to my knowledge, not compatible.
    Can you just advise me on any GPU < 500$/€?

    • Hi,

      I am not the right person to ask this question. This because what I use in my late 2013 MacPro isn’t even available for (retail) sale, and in my hack I only use the IGPU. Sorry, but you be better off somewhere else.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s