Jump to content
30960 posts in this topic

Recommended Posts

3. GPT partitioning. Recommended scheme. Reliable for Windows UEFI booting.

No active partitions.

boot0af in Master Boot Record. sector 0 of whole drive.

boot1f32v2 in first sector of EFI partiton (PBR sector)

boot file (Legacy Clover) and EFI folder with Clover on the next (HFS+) partition.

boot1f32v2 so clever that it looks on the next NFS+ partition after finding nothing on the EFI partition.

 

\o/

 

NOT POSSIBLE. There is not enough room to add this extensive code, not to mention after boot0 passes to boot1, it's probably going to be pretty difficult to just figure out the next partition, let alone all the code needed to search for the boot firmware file on the partition - this already takes up most of the code area available. And yes you can make the partition active in a hybrid GPT/MBR. You realize also that if you are booting legacy you can just skip using the EFI partition all together... Just install straight to the macOS volume... You're asking for something that you could do yourself in like five minutes but would take forever to code, like literally forever because it couldn't happen, there's just not enough space for the instructions. Otherwise there would be no need for the boot firmware at all, we could just put it at boot0 or boot1....

  • Like 3

Clover working very well here on my legacy BIOS machines, installed in EFI system partition on GPT formatted drives.  How did you install Clover?

 

With the Clover pkg installer, after selecting the target OSX volume, I select "customize" with the following options...

 

 

 

The Clover wiki describes the legacy booting process:

 

Essentially BIOS--->MBR--->PBR--->boot--->CLOVERX64.efi--->OSLoader

 

In terms of the bootsectors:

BIOS--->boot0af in MBR--->boot1f32 in the PBR of the EFI System Partition--->boot6 in ESP--->CLOVERX64.efi in ESP--->OSLoader

That works for me too.

 

 

For the Legacy boot it will still be difficult to get there

 

Here I see a portion of the script postinstall for Legacy boot
 
if [[ ${boot_volume_format} = "hfs" ]]; then
    echo "Stage 1 - Writting ${partitionloaderhfs} to ${bootrdev}" >> "$install_log"
    echo "File system is HFS." >> "$install_log"
    echo "dd if=${DEST_VOL}/usr/standalone/i386/${partitionloaderhfs} of=${bootrdev}" >> "$install_log"
    dd if="${DEST_VOL}/usr/standalone/i386/${partitionloaderhfs}" of=${bootrdev}
 
 
 
I do not know if this can be done on System APFS  :)
I am a simple Packager and not Coder but I am concerned with the use of Package Clover in the Future
I do not have the knowledge to get to know it and do it

 

 

 

 Chris, can you not just install Clover to a prepared Flash drive, configure it the way you want with Configurator, and then copy the EFI folder and boot file to the APFS EFI? I have probably just described the way you guys are already doing it!

That works for me too.

 

 

 

 Chris, can you not just install Clover to a prepared Flash drive, configure it the way you want with Configurator, and then copy the EFI folder and boot file to the APFS EFI? I have probably just described the way you guys are already doing it!

Yes 

You can use the Clover package legacy install or UEFI on a HFS + J blank volume.
Then do a High Sierra install and convert APFS, the volumes will always be bootable and the boot files will be present

 

Yes 

You can use the Clover package legacy install or UEFI on a HFS + J blank volume.
Then do a High Sierra install and convert APFS, the volumes will always be bootable and the boot files will be present

 

If I understand you correctly I can convert the EFI partition to APFS. Right now when I right click  on the EFI and choose get info it is saying format is Fat-32

If I understand you correctly I can convert the EFI partition to APFS. Right now when I right click  on the EFI and choose get info it is saying format is Fat-32

No  No    :surprised:

 

the EFI partition must always be in FAT32

I'm talking about Volumes High Sierra, sorry if you do not understand my English, I thought I was clear

 

No  No    :surprised:

 

the EFI partition must always be in FAT32

I'm talking about Volumes High Sierra, sorry if you do not understand my English, I thought I was clear

 

No you were clear. It's my own  confusion.  I had originally installed High Sierra first in HFS and then converted to APFS.  My recent installs have been installed as APFS. Now I get it!

No you were clear. It's my own  confusion.  I had originally installed High Sierra first in HFS and then converted to APFS.  My recent installs have been installed as APFS. Now I get it!

Ok Great  :)

Guys, I am sorry, I totally seem to miss the existence of "boot0hfs". But AFAIK it is not included into clover installer as an option. Can you add it then?


Ok, I am at beginning again. I now installed boot0hfs to my pure GPT drive, and boot1h2 to the first HFS system partition. Strangely the boot1h2 or boot0hfs seems to scan the whole hdd tree first, before loading clover from whatever partition :P  

 

Please tell me in my case (legacy bios mode, pure GPT formatted HDD, clover on HFS system partition): What boot0 / boot1 variants do I have to choose, and on what partition do I need to place boot1 then?

 

Is there a way to see from what hdd and partition clover did start?

Hi folks,

 

Would anyone have time to check these portions of my Clover boot.log and see if what appears to be happening twice actually is?

 

Note the 4 patches...

3:916  0:000  === [ FixBiosDsdt ] =======================================
3:916  0:000  VideoCard devID=0x1628086
3:916  0:000  DisplayADR1[0] = 0x20000, DisplayADR2[0] = 0xFFFE
3:916  0:000  USBADR[0] = 0x140000 and PCIe = 0xFFFE
3:916  0:000  USBADR[1] = 0x1A0000 and PCIe = 0xFFFE
4:046  0:130  Found Airport BCM at 0x1C0004, 0x0
4:046  0:000  USBADR[2] = 0x1D0000 and PCIe = 0xFFFE
4:046  0:000  Patching DSDT:
4:046  0:000   - [Convert COPR to MATH]: pattern 434F5052, patched at: [ (3146) ]
4:047  0:000   - [Convert TPMX to MEM2]: pattern 54504D58, patched at: [ (1B50) ]
4:047  0:000   - [Convert SAT0 to SATA]: pattern 53415430, patched at: [ (692D) ]
4:047  0:000   - [Convert GFX0 to IGPU]: pattern 47465830, patched at: [ (7450) (13C3) (12) (5C8) (19) (F) (9B0) (20) (20) (20) (20) (20) (20) (20) (8F2) (14) (110C) ]

They seem to happen lower down here too...

4:048  0:000  === [ PatchAllSSDT ] ======================================
4:048  0:000  Patch table: SSDT  SataTabl len=0x36D
4:048  0:000  0. [Convert COPR to MATH]: pattern 434F5052, bin not found / already patched!
4:048  0:000  1. [Convert TPMX to MEM2]: pattern 54504D58, bin not found / already patched!
4:048  0:000  2. [Convert SAT0 to SATA]: pattern 53415430, patched at: [ (B5) ]
4:048  0:000  3. [Convert GFX0 to IGPU]: pattern 47465830, bin not found / already patched!
4:048  0:000  Drop tables from Xsdt, SIGN=XXXX TableID= Length=0
4:048  0:000   Xsdt has tables count=6

Is this something that automatically happens with Clover now and I just haven't removed the patches from my Config.plist?

fusion71au:

 

But managing a clover installation on a by default hidden EFI partition is a pain in the ass. Why boot0 or boot1 cannot simply look on the next partition, if the EFI partition is empty? 

 

Also the installation on the system partition is a best practise for backups. The clover setup will be backed up, too, so my backup drive can fully boot in the same way.

 

Etc.

 

EFI partition is ugly, system partition is beauty.

 

 

I mean some logic like this:

 

1. boot0 loads and checks for boot1 on 1st partition

2. boot1 of partition 1 doesn't find clover on this partition and returns false, returns back to boot0

3. boot0 tries the next partition on the same drive for a boot1

4. boot1 of partition 2 finds clover and loads it -> lot of headaches gone

 

And when you format your drive you lose everything.  My EFI keeps all important files and for me I have plenty of legacy PC see my signature and I would never go any other way but EFI partition.  

  • Like 1

And when you format your drive you lose everything.  My EFI keeps all important files and for me I have plenty of legacy PC see my signature and I would never go any other way but EFI partition.  

Erase Drive disk Utility erase also EFI Partition  :P

 

 

post-951341-0-37643500-1503963574_thumb.png

  • Like 1

No, that's definitely out of the scope of Clover (or any UEFI application/driver, really). It's simply not possible without directly modifying the ME's firmware, which is what me_cleaner does (on SKL/KBL with ME v11.x it sets the reserve_hap bit in the PCH strap, in addition to removing unnecessary modules like it does for older ME firmware revisions).

 

Edit: The dev branch of me_cleaner also now sets the reserve_hap bit for older ME versions (in addition to the previous removal of most of the firmware modules).

 

If you don't know what this means, ignore it. Don't mess with ME/etc unless you know what you're doing.

  • Like 1

No, that's definitely out of the scope of Clover (or any UEFI application/driver, really). It's simply not possible without directly modifying the ME's firmware, which is what me_cleaner does (on SKL/KBL with ME v11.x it sets the reserve_hap bit in the PCH strap, in addition to removing unnecessary modules like it does for older ME firmware revisions).

 

Edit: The dev branch of me_cleaner also now sets the reserve_hap bit for older ME versions (in addition to the previous removal of most of the firmware modules).

 

If you don't know what this means, ignore it. Don't mess with ME/etc unless you know what you're doing.

 

Thanks for the explanation, mate.

Hi folks,

 

Would anyone have time to check these portions of my Clover boot.log and see if what appears to be happening twice actually is?

 

Note the 4 patches...

3:916  0:000  === [ FixBiosDsdt ] =======================================
3:916  0:000  VideoCard devID=0x1628086
3:916  0:000  DisplayADR1[0] = 0x20000, DisplayADR2[0] = 0xFFFE
3:916  0:000  USBADR[0] = 0x140000 and PCIe = 0xFFFE
3:916  0:000  USBADR[1] = 0x1A0000 and PCIe = 0xFFFE
4:046  0:130  Found Airport BCM at 0x1C0004, 0x0
4:046  0:000  USBADR[2] = 0x1D0000 and PCIe = 0xFFFE
4:046  0:000  Patching DSDT:
4:046  0:000   - [Convert COPR to MATH]: pattern 434F5052, patched at: [ (3146) ]
4:047  0:000   - [Convert TPMX to MEM2]: pattern 54504D58, patched at: [ (1B50) ]
4:047  0:000   - [Convert SAT0 to SATA]: pattern 53415430, patched at: [ (692D) ]
4:047  0:000   - [Convert GFX0 to IGPU]: pattern 47465830, patched at: [ (7450) (13C3) (12) (5C8) (19) (F) (9B0) (20) (20) (20) (20) (20) (20) (20) (8F2) (14) (110C) ]

They seem to happen lower down here too...

4:048  0:000  === [ PatchAllSSDT ] ======================================
4:048  0:000  Patch table: SSDT  SataTabl len=0x36D
4:048  0:000  0. [Convert COPR to MATH]: pattern 434F5052, bin not found / already patched!
4:048  0:000  1. [Convert TPMX to MEM2]: pattern 54504D58, bin not found / already patched!
4:048  0:000  2. [Convert SAT0 to SATA]: pattern 53415430, patched at: [ (B5) ]
4:048  0:000  3. [Convert GFX0 to IGPU]: pattern 47465830, bin not found / already patched!
4:048  0:000  Drop tables from Xsdt, SIGN=XXXX TableID= Length=0
4:048  0:000   Xsdt has tables count=6

Is this something that automatically happens with Clover now and I just haven't removed the patches from my Config.plist?

 

I think this is the normal / expected behavior : 

 

The first log is for DSDT :

4:046  0:000  Patching DSDT: 

The second is for SSDT :

4:048  0:000  === [ PatchAllSSDT ] ======================================
  • Like 1

Hey,

 

quick question which I think I know the answer too...

Can Clover boot from NetInstall, or NetBoot images hosted with OS X Server, No right?

hey

how I can fix this ?

SPD[1]: Got invalid type 0 @0x51. Will set page and retry.

thx in advance

 

What are the lines after this? It's probably that you have DDR4 and it is not reading from the first page of the SPD for that module. So it gets a weird value, says that and attempts to set the page to the first one, I'm assuming it then determines your memory fine after that?

 

 

Hey,

 

quick question which I think I know the answer too...

Can Clover boot from NetInstall, or NetBoot images hosted with OS X Server, No right?

 

No. I couldn't even get it to work on some macs, lol.

What are the lines after this? It's probably that you have DDR4 and it is not reading from the first page of the SPD for that module. So it gets a weird value, says that and attempts to set the page to the first one, I'm assuming it then determines your memory fine after that?

 

 

 

No. I couldn't even get it to work on some macs, lol.

I apianti  :)

I think It works with Deploy Studio ?

Also imagr, CasperNetInstallCreator ?

I tried 5 or 6 years ago, I let go of it I could be discouraged, I did not know much about Mac

If Clover could integrate Booting the Net boot install it would be a big plus with lots of fun

What are the lines after this? It's probably that you have DDR4 and it is not reading from the first page of the SPD for that module. So it gets a weird value, says that and attempts to set the page to the first one, I'm assuming it then determines your memory fine after that?

 === [ ScanSPD ] ===========================================
0:567  0:000  SMBus device : 8086 A123 class=0C0500 status=Success
0:567  0:000  SMBus CmdReg: 0x3
0:567  0:000  Scanning SMBus [8086:A123], mmio: 0xF7F4A004, ioport: 0xF000, hostc: 0x11
0:567  0:000  Slots to scan [8]...
0:567  0:000  SPD[1]: Got invalid type 0 @0x51. Will set page and retry.
0:568  0:000  SPD[1]: Type 12 @0x51
0:586  0:017  Unknown vendor bank=0x83 code=0x13
0:586  0:000  XMP Profile1: 7*125 -42 ns
0:586  0:000  Found module with XMP version 2.0
0:586  0:000  DDR speed 2132MHz
0:586  0:000  Slot: 1 Type 26 8192MB 2132MHz Vendor=NoName PartNo=CL16-16-16D4-2400 SerialNo=0000000000000000
0:586  0:000  SPD[3]: Type 12 @0x53
0:604  0:017  Unknown vendor bank=0x83 code=0x13
0:604  0:000  XMP Profile1: 7*125 -42 ns
0:604  0:000  Found module with XMP version 2.0
0:604  0:000  DDR speed 2132MHz
0:604  0:000  Slot: 3 Type 26 8192MB 2132MHz Vendor=NoName PartNo=CL16-16-16D4-2400 SerialNo=0000000000000000

 

 === [ ScanSPD ] ===========================================
0:567  0:000  SMBus device : 8086 A123 class=0C0500 status=Success
0:567  0:000  SMBus CmdReg: 0x3
0:567  0:000  Scanning SMBus [8086:A123], mmio: 0xF7F4A004, ioport: 0xF000, hostc: 0x11
0:567  0:000  Slots to scan [8]...
0:567  0:000  SPD[1]: Got invalid type 0 @0x51. Will set page and retry.
0:568  0:000  SPD[1]: Type 12 @0x51
0:586  0:017  Unknown vendor bank=0x83 code=0x13
0:586  0:000  XMP Profile1: 7*125 -42 ns
0:586  0:000  Found module with XMP version 2.0
0:586  0:000  DDR speed 2132MHz
0:586  0:000  Slot: 1 Type 26 8192MB 2132MHz Vendor=NoName PartNo=CL16-16-16D4-2400 SerialNo=0000000000000000
0:586  0:000  SPD[3]: Type 12 @0x53
0:604  0:017  Unknown vendor bank=0x83 code=0x13
0:604  0:000  XMP Profile1: 7*125 -42 ns
0:604  0:000  Found module with XMP version 2.0
0:604  0:000  DDR speed 2132MHz
0:604  0:000  Slot: 3 Type 26 8192MB 2132MHz Vendor=NoName PartNo=CL16-16-16D4-2400 SerialNo=0000000000000000

 

Looks fine except for the bank number for the vendor. The bank number is 0x83 but the code expects 3 because it does not take into account that the most significant bit is an odd parity bit.

 

The code in file spd.c for DDR3 masks off the parity bit. Maybe the DDR4 code should do the same. Maybe both the DDR3 and DDR4 code should check the parity first and at least give an error message if it's wrong, then mask off the parity bit:

UINT8 parity = bank;
UINT8 testbit = bank;
for (i=6; i >= 0; i--) { parity ^= (testbit <<= 1); }
if ( (parity & 0x80) == 0 ) {
    DBG("Bad parity bank=0x%2X code=0x%2X\n", bank, code);
}
bank &= 0x7f;

Bank 3, code 0x13 is manufacturer "Geil". Is that correct for your ram?

 

How does this SPD data compare to the "Get Smbios" part of the log? Is there a valid manufacturer name there?

  • Like 2

Looks fine except for the bank number for the vendor. The bank number is 0x83 but the code expects 3 because it does not take into account that the most significant bit is an odd parity bit.

 

The code in file spd.c for DDR3 masks off the parity bit. Maybe the DDR4 code should do the same. Maybe both the DDR3 and DDR4 code should check the parity first and at least give an error message if it's wrong, then mask off the parity bit:

UINT8 parity = bank;
UINT8 testbit = bank;
for (i=6; i >= 0; i--) { parity ^= (testbit <<= 1); }
if ( (parity & 0x80) == 0 ) {
    DBG("Bad parity bank=0x%2X code=0x%2X\n", bank, code);
}
bank &= 0x7f;
Bank 3, code 0x13 is manufacturer "Geil". Is that correct for your ram?

 

How does this SPD data compare to the "Get Smbios" part of the log? Is there a valid manufacturer name there?

 

yes is GEIL manufacture 

 

will try to added it to spd.c and test thx

0:100  0:000  === [ Get Smbios ] ========================================
0:100  0:000  Type 16 Index = 0
0:100  0:000  Total Memory Slots Count = 4
0:100  0:000  Type 17 Index = 0
0:100  0:000  Ignoring insane frequency value 0MHz
0:100  0:000  SmbiosTable.Type17->Speed = 0MHz
0:100  0:000  SmbiosTable.Type17->Size = 0MB
0:100  0:000  SmbiosTable.Type17->Bank/Device = BANK 0 DIMM_A1
0:100  0:000  SmbiosTable.Type17->Vendor = <null string>
0:100  0:000  SmbiosTable.Type17->SerialNumber = <null string>
0:100  0:000  SmbiosTable.Type17->PartNumber = <null string>
0:100  0:000  Type 17 Index = 1
0:100  0:000  SmbiosTable.Type17->Speed = 2400MHz
0:100  0:000  SmbiosTable.Type17->Size = 8192MB
0:100  0:000  SmbiosTable.Type17->Bank/Device = BANK 1 DIMM_A2
0:100  0:000  SmbiosTable.Type17->Vendor = GEIL
0:100  0:000  SmbiosTable.Type17->SerialNumber = 00000000
0:100  0:000  SmbiosTable.Type17->PartNumber = CL16-16-16 D4-2400  
0:100  0:000  Type 17 Index = 2
0:100  0:000  Ignoring insane frequency value 0MHz
0:100  0:000  SmbiosTable.Type17->Speed = 0MHz
0:100  0:000  SmbiosTable.Type17->Size = 0MB
0:100  0:000  SmbiosTable.Type17->Bank/Device = BANK 2 DIMM_B1
0:100  0:000  SmbiosTable.Type17->Vendor = <null string>
0:100  0:000  SmbiosTable.Type17->SerialNumber = <null string>
0:100  0:000  SmbiosTable.Type17->PartNumber = <null string>
0:100  0:000  Type 17 Index = 3
0:100  0:000  SmbiosTable.Type17->Speed = 2400MHz
0:100  0:000  SmbiosTable.Type17->Size = 8192MB
0:100  0:000  SmbiosTable.Type17->Bank/Device = BANK 3 DIMM_B2
0:100  0:000  SmbiosTable.Type17->Vendor = GEIL
0:100  0:000  SmbiosTable.Type17->SerialNumber = 00000000
0:100  0:000  SmbiosTable.Type17->PartNumber = CL16-16-16 D4-2400  

Feature request: Fix brightness range (max brightness) on 10.12.4+ (tested on HD3000)

         

           OperationRegion (IGD5, PCI_Config, Zero, 0x14)            Field (IGD5, AnyAcc, NoLock, Preserve)

            {
                Offset (0x10), 
                BAR1,   32
            }


            OperationRegion (RMB1, SystemMemory, (BAR1 & 0xFFFFFFFFFFFFFFF0), 0x000E1184)
            Field (RMB1, AnyAcc, Lock, Preserve)
            {
                Offset (0xC8250), 
                LEVW,   32, 
                LEVX,   32
            }


            Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                LEVX = 0x07100000
            }

 

 

Setting LEVX to 1007 (max brightness for Sandy Bridge) gives me full range of brightness using AppleBacklight.kext without having to binary patch. I think this could be implemented the same way as SetIntelBacklight (which doesn't fully work for me BTW, breaks brightness slider).

 

Hope more people find this useful.

 

 

×
×
  • Create New...