macOS boot.efi developer's thread

[busitech]

To get the install started, I did not modify any aspect of the installer partition except boot.efi (x3). However, after "preparing for installation" there is a reboot. I had to replace boot.efi (x1) in the .IABootFiles folder, and restart from the installer partition. After installation was complete, I had to replace boot.efi again in the (x2) usual places on the boot volume.

Here is my ioreg output from within El Capitan:

+-o MacPro2,1 <class IOPlatformExpertDevice, id 0x100000112, registered, matched, active, busy 0 (160582 ms), retain 30>
| {
| "compatible" = <"MacPro2,1">
| "version" = <"1.0">
| "board-id" = <"Mac-F42C88C8">
| "IOInterruptSpecifiers" = (<0900000005000000>)
| "IOPolledInterface" = "SMCPolledInterface is not serializable" | "IOInterruptControllers" = ("io-apic-0")
| "clock-frequency" = <00b5644f>
| "manufacturer" = <"Apple Computer, Inc.">
| "IOConsoleSecurityInterest" = "IOCommand is not serializable"
| "system-type" = <03>
| "product-name" = <"MacPro2,1">
| "model" = <"MacPro2,1">
| "name" = <"/">
| "IOBusyInterest" = "IOCommand is not serializable"
| }

 

[Pike R. Alpha]

To get the install started, I did not modify any aspect of the installer partition except boot.efi (x3). However, after "preparing for installation" there is a reboot. I had to replace boot.efi (x1) in the .IABootFiles folder, and restart from the installer partition. After installation was complete, I had to replace boot.efi again in the (x2) usual places on the boot volume.

Here is my ioreg output from within El Capitan:

+-o MacPro2,1 <class IOPlatformExpertDevice, id 0x100000112, registered, matched, active, busy 0 (160582 ms), retain 30>
| {
| "compatible" = <"MacPro2,1">
| "version" = <"1.0">
| "board-id" = <"Mac-F42C88C8">
| "IOInterruptSpecifiers" = (<0900000005000000>)
| "IOPolledInterface" = "SMCPolledInterface is not serializable" | "IOInterruptControllers" = ("io-apic-0")
| "clock-frequency" = <00b5644f>
| "manufacturer" = <"Apple Computer, Inc.">
| "IOConsoleSecurityInterest" = "IOCommand is not serializable"
| "system-type" = <03>
| "product-name" = <"MacPro2,1">
| "model" = <"MacPro2,1">
| "name" = <"/">
| "IOBusyInterest" = "IOCommand is not serializable"
| }

Ok that looks right. Your board-id is now set to that of a MacPro3,1

Now. I did find something we should fix. Normally, we first set the checksum to 0 so what happens when you add:

factoryEPS->DMI.Checksum = 0;
factoryEPS->Checksum = 0;

Just above the Checksum8() calls?

p.s. You can now also download El Capitan from the App Store?

 

[Pike R. Alpha]

New commit available for compilation/testing.

 

[PeterHolbrook]

Commit 92e79ca974210a8acc3c255eaf0630a9cc8a7a97 compilation errors:

Error 1 error C2664: 'UINTN strlen(const CHAR8 *)' : cannot convert argument 1 from 'const char [13]' to 'const CHAR8 *' C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\PlatformExpert.cpp 262 1 boot
Error 2 error C2660: 'memcpy' : function does not take 2 arguments C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\PlatformExpert.cpp 262 1 boot

 

[randyoo]

Commit 92e79ca974210a8acc3c255eaf0630a9cc8a7a97 compilation errors:

Error 1 error C2664: 'UINTN strlen(const CHAR8 *)' : cannot convert argument 1 from 'const char [13]' to 'const CHAR8 *' C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\PlatformExpert.cpp 262 1 boot
Error 2 error C2660: 'memcpy' : function does not take 2 arguments C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\PlatformExpert.cpp 262 1 boot

Anything specific that should be tested on the next build? Just need debug output screenshot, or also ioreg output? Or attempt an install again?

 

[Pike R. Alpha]

Anything specific that should be tested on the next build? Just need debug output screenshot, or also ioreg output? Or attempt an install again?

The ioreg data (compatible/model and board-id) when it compiles.

Edit: @PeterHolbrook,

Can you change that line into:

memcpy((CHAR8 *)startOfStringTable, (CHAR8 *)BOARD_ID_REPLACEMENT, strlen((CHAR8 *)BOARD_ID_REPLACEMENT));

 

[PeterHolbrook]

Pike, there are compilation errors. Read message #279.

 

[PeterHolbrook]

Almost there.

(One line of code has been slightly altered)

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[Pike R. Alpha]

Almost there.

(One line of code has been slightly altered)

Thanks Peter,

I did one last commit before going away for an appointment. Look at the comments I added. In short. Comment out the four Checksum8() lines when required (Apple may have checks in place/something weird is going on).

After that we may want to add a board-id replacement table for unsupported hardware (have MacPro1,1 and MacPro2,1 covered already).

 

[PeterHolbrook]

Small changes.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[randyoo]

The ioreg data (compatible/model and board-id) when it compiles.

Build 99b39a...

Attached debug output photo. "ioreg" output is missing lots of info, like before. (due to corruption?)

bash-3.2# ioreg -p IODeviceTree -d 2 -k board-id
+-o Root  <class IORegistryEntry, id 0x100000100, retain 13>
  +-o /  <class IOPlatformExpertDevice, id 0x100000111, registered, matched, active, busy 0 (144049 ms), retain 27>
-bash-3.2# ioreg -p IODeviceTree -r -n / -d 1
+-o /  <class IOPlatformExpertDevice, id 0x100000111, registered, matched, active, busy 0 (144049 ms), retain 27>
    {
      "IOBusyInterest" = "IOCommand is not serializable"
      "compatible" = <"Apple002,1">
      "IOPlatformUUID" = "2B12FE1B-1090-593B-B740-XXXXXXXXXXXX"
      "IOConsoleSecurityInterest" = "IOCommand is not serializable"
      "system-type" = <03>
      "model" = <"Apple002,1">
      "IOPolledInterface" = "SMCPolledInterface is not serializable"
      "IOInterruptControllers" = ("io-apic-0")
      "IOInterruptSpecifiers" = (<0900000005000000>)
      "name" = <"/">
      "clock-frequency" = <00e1f505>
    }


-bash-3.2#

 

[splifingate]

commit 99b39ea6

No apparent change in ioreg output.

Install OS X --> "OS X El Capitan is already installed..."

 

[Pike R. Alpha]

Right. That was not working. New commit available for compilation/testing.

 

[PeterHolbrook]

Don't update the checksums.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[PeterHolbrook]

Fix checksum calculation.

Line 269 of AcpiUtils.cpp rewritten as

return (UINT8) (256 - csum);

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[Pike R. Alpha]

Fix checksum calculation.

Line 269 of AcpiUtils.cpp rewritten as

return (UINT8) (256 - csum);

Ah yes the Microsoft compiler limitation. Thanks. Can you confirm that this compiles?
return ((UINT8)256 - csum);

Edit: People who can compile & test the latest commits should try to include these two lines:

factoryEPS->DMI.Checksum = 0;
factoryEPS->Checksum = 0;

Note that I did comment them out, but we need to figure out if setting the checksum is the problem, or that the calls to Checksum8() are failing. My guess would be the latter, but if the above two lines fail, then please also try these:

factoryEPS->DMI.Checksum = (UINT8)0;
factoryEPS->Checksum = (UINT8)0;

SMBIOS data corruption may occur when 0 is not UINT8 but bigger. Then everything shifts up and poof.

 

[busitech]

I will have time to test both approaches this evening unless another user beats me to it.

 

[PeterHolbrook]

Can you confirm that this compiles?
return ((UINT8)256 - csum);

Edit: People who can compile & test the latest commits should try to include these two lines:

factoryEPS->DMI.Checksum = 0;
factoryEPS->Checksum = 0;

Note that I did comment them out, but we need to figure out if setting the checksum is the problem, or that the calls to Checksum8() are failing. My guess would be the latter, but if the above two lines fail, then please also try these:

factoryEPS->DMI.Checksum = (UINT8)0;
factoryEPS->Checksum = (UINT8)0;

SMBIOS data corruption may occur when 0 is not UINT8 but bigger. Then everything shifts up and poof.

No, Pike. That's the first thing I tried when the error showed up, but that won't compile (at least on MVS 2013; perhaps the 2015 version behaves differently).

As for uncommenting those lines, I take it that you'd rather let splifingate or someone else capable of compiling and running it change the code. I'll gladly compile again when I see a new commit.

 

[Pike R. Alpha]

No, Pike. That's the first thing I tried when the error showed up, but that won't compile (at least on MVS 2013; perhaps the 2015 version behaves differently).

Thanks. Don't understand how a UINT8 can morph into a UINT16, UINT32 or UINT64 nut hey. Crazy stuff the MS compilers.

As for uncommenting those lines, I take it that you'd rather let splifingate or someone else capable of compiling and running it change the code. I'll gladly compile again when I see a new commit.

I'll let you know when we're ready for it.

I have the feeling that we are almost there, for the Mac Pro's. Not so for other unsupported hardware, because then we need to add more board-id replacement code, but the kernel patcher, installer detection are done and working. Great stuff.

 

[splifingate]

269: return((UINT8)256 - csum);

fails build in VSE2015/Win10, same as Peter . . . working on PlatformExpert.cpp AIT...

[edit]

Un-commenting lines 298 and 304 in PlatformExpert.cpp fails teh build in both instances when modding line 269 as you suggest.

Only when I make AcpiUtils.cpp:269: (UINT8) (256 - csum) as Peter suggested does the build succeed (in all instances).

Interestingly, if I change AcpiUtils.cpp:269: to return ((UINT8) (256 - csum));

the build succeeds.

[/edit]

[edit:edit]

Boot into createinstallmedia environment succeeds with the addition of that successful build, yet with the same results as prior, and "...El Cap is already installed..."

[/edit:edit]

 

[busitech]

yet with the same results as prior

I'm not sure if it is of any consolation that the upgrade process and the operating system itself seems to ignore the checksums...

 

[busitech]

p.s. You can now also download El Capitan from the App Store?

Yes I can.

 

[splifingate]

I'm not sure if it is of any consolation that the upgrade process and the operating system itself seems to ignore the checksums...

Good stuff, @busitech

I can get ElCap installed in a matter of minutes, but I'm game to play CSI: Pike till teh Goal comes Home

btw, which commit did you use to accomplish this?

I've run-through so many git source control commits, I lose track, but I would like to source that particular commit for verification. . . .

 

[busitech]

which commit did you use to accomplish this?

I used 460310bd54ea5fb9138b74db13c7b3047ce47bc9 without setting the two checksums.

 

[splifingate]

I used 460310bd54ea5fb9138b74db13c7b3047ce47bc9 without setting the two checksums.

thx