macOS boot.efi developer's thread

[splifingate]

thx

commit 460310bd; lines 319 & 320 // commented

(more to come...)

 

[splifingate]

commit 460310bd; lines 319 & 320 // commented

(more to come...)

Option -> Yosemite (working install) directly after installer re-boot...

Contents are locked.

 

[splifingate]

Option -> Yosemite (working install) directly after installer re-boot...

Contents are locked.

Deceptive…the ".IABootFiles" is in the original createinstallmedia partition, is modded after teh install process, and is locked from casual viewing/editing.

Allowed 'Everyone', and replaced the stock ~600kb boot.efi with the ~300kb from the compile of commit 460310bd.

Re-booting, AIT…

 

[splifingate]

Deceptive…the ".IABootFiles" is in the original createinstallmedia partition, is modded after teh install process, and is locked from casual viewing/editing.

Allowed 'Everyone', and replaced the stock ~600kb boot.efi with the ~300kb from the compile of commit 460310bd.

Re-booting, AIT…

Doing its thing (BTDT).

Just wanted to verify.

Thanks for the pointers, @busitech

 

[splifingate]

Doing its thing (BTDT).

Just wanted to verify.

Thanks for the pointers, @busitech

10.11 Recovery HD created (not boot-able on this 1,1->2,1, because of teh stock 600kb+ boot.efi's, of course).

 

[splifingate]

10.11 Recovery HD created (not boot-able on this 1,1->2,1, because of teh stock 600kb+ boot.efi's, of course).

'Untitled' re-named to "El Capitan"

 

[splifingate]

'Untitled' re-named to "El Capitan"

Full-on environ...

 

[busitech]

I think I understand these two checksums now, after reading a few pages (21-22) of the SMBIOS Specification. We don't need to update these checksums, because they should not be affected by the board-id change. The area of memory being checksummed is just the entry point structure, only 0x1F bytes, and the intermediate entry point structure, only 0x0F bytes. Correct?

 

[Pike R. Alpha]

I think I understand these two checksums now, after reading a few pages (21-22) of the SMBIOS Specification. We don't need to update these checksums, because they should not be affected by the board-id change. The area of memory being checksummed is just the entry point structure, only 0x1F bytes, and the intermediate entry point structure, only 0x0F bytes. Correct?

Correct. We don't need it right now because, strangely enough... Apple allows us to poke memory locations that should be protected, and they can change this pretty quick, so we better be prepared for it.

I'd also like to know if we can remove these lines:

startOfStringTable = Add2Ptr(startOfStringTable, strlen((CHAR8 *)BOARD_ID_REPLACEMENT), UINT8*);
startOfStringTable = 0x00;

After that I will do some more cleanups and update the files on this page http://piker-alpha.github.io/macosxbootloader/

 

[PeterHolbrook]

I'd also like to know if we can remove these lines:

startOfStringTable = Add2Ptr(startOfStringTable, strlen((CHAR8 *)BOARD_ID_REPLACEMENT), UINT8*);
startOfStringTable = 0x00;

After that I will do some more cleanups and update the files on this page http://piker-alpha.github.io/macosxbootloader/

Do you want me to remove them for you or are you going to make other changes?

 

[Pike R. Alpha]

Do you want me to remove them for you or are you going to make other changes?

Thank you Peter. Good idea. This way people without a compiler can test it for us.

 

[PeterHolbrook]

Fix checksum calculation (modified).

Lines 267 and 268 of PlatformExpert.cpp have been commented out.

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]

Prevent compilation error.

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!

 

[splifingate]

Commit bc25a0af

built with, and without, commented-out lines: each hangs with "Waiting for DSMOS..."

 

[randyoo]

Prevent compilation error.

Running this build (bc25a0af), hangs, doesn't reach GUI. Debug messages and screenshot of verbose boot messages attached.

 

[Pike R. Alpha]

Are we still talking about the installer or normal boot?

Edit: I checked the last five commits and they cannot be causing this. The yard meaningless changes, though there are two other parts that may be failing. Please test this change:

-memcpy((CHAR8 *)startOfStringTable, (CHAR8 *)BOARD_ID_REPLACEMENT, strlen((CHAR8 *)BOARD_ID_REPLACEMENT));
+memcpy((CHAR8 *)startOfStringTable, (CHAR8 *)"Mac-F42C88C8", 12);

-startOfStringTable = Add2Ptr(startOfStringTable, strlen((CHAR8 *)BOARD_ID_REPLACEMENT), UINT8*);
+startOfStringTable = Add2Ptr(startOfStringTable, 12, UINT8*);

Also. Look for this if(ArchNeedEFI64Mode()) {
and add this line:
+CsPrintf(CHAR8_CONST_STRING("PIKE: SMBIOS ArchNeedEFI64Mode()\n"));

Note: Lines that start with "-" are current lines and lines with a "+" are new lines. Only add new lines without the "+".

New commit with changes available for compilation/testing.

 

[randyoo]

Are we still talking about the installer or normal boot?

Installer, created via the official "createinstallmedia" command, having only replaced the three boot.efi files.

 

[Pike R. Alpha]

Installer, created via the official "createinstallmedia" command, having only replaced the three boot.efi files.

Ok. Thanks. See my edit.

 

[randyoo]

Ok. Thanks. See my edit.

I'm afraid I have no ability to compile/build your bootloader. I've been watching this thread for any opportunity to help test a new build, once somebody posts one, but that's all I'm able to do, unfortunately. Sorry.

 

[Pike R. Alpha]

I'm afraid I have no ability to compile/build your bootloader. I've been watching this thread for any opportunity to help test a new build, once somebody posts one, but that's all I'm able to do, unfortunately. Sorry.

No problem. Peter is here to help people like you. Thanks for testing the changes, and if the next version of boot.efi also hangs, then please report if you see this line: "PIKE: SMBIOS ArchNeedEFI64Mode()".

 

[PeterHolbrook]

Investigating hang.

Removed extra closing parenthesis on line 264 of PlatformExpert.cpp

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]

Investigating hang.

Removed extra closing parenthesis on line 264 of PlatformExpert.cpp

Thanks Peter!

 

[busitech]

Here is a screenshot. Starting from the latest commit, I took out the code adding the null terminator, and went back to the hard coded board string. I too am hanging at Waiting for DSMOS now. I am going to erase my installer media, which was used previously, and retry with a fresh copy.

 

[randyoo]

Build 0e193cd, no longer hanging. Reached installer GUI, and able to start the install without the previously encountered error ("OS X El Capitan is already installed on this mac"). Not enough time to completely test the install tonight.

Also, ioreg command output now shows the correct product name, manufacturer, serial number, etc that were previously missing.

Still have "MacPro2,1" as model name, though.

So once we have a script to protect/prevent Pike's boot.efi from being replaced, then we have a nearly perfect solution!

Thanks Pike, Peter, splifingate, and everyone else who has been working on this!

 

[Sko]

I am finally on El Capitan. Thanks to everyone, especially Pike, Peter and Mike.

Latest commit worked flawlessly on newly created CIM. I had to replace boot.efi in .IABootFiles on first restart and in the usual places on the finished boot drive.

Board ID was changed to Mac-F42C88C8 and is still shown in ioreg.

Here is the debug output: