Jump to content

Clover General discussion


ErmaC
29,866 posts in this topic

Recommended Posts

Interesting. I don't use it on any of my systems, all booting UEFI.

This is a question for debugging if you want to check.

He said about reboot, I proposed DataHubDxe missing. It is cause and reason.

OsxAptioFix2Drv and DataHubDxe make a this problem:

attachicon.gifIMAG0096.jpg

error allocating pages is the most discussed question in UEFI booting.

There are workarounds:

1. Use different AptioFix/LowMemFix versions.

2. Use slide=something

3. Disable SIP entirely

4. Reboot twice

5. Restrict a number of custom kexts

6. Optimize your BIOS settings

If nothing helped then use legacy Clover.

Link to comment
Share on other sites

Same. I have it and PartitionDxe under DisableDrivers on all three of my installs.

If you look at the source, DataHub appears to relay important variables to the OS. So I use it anyway, even though the system can ostensibly boot fine w/o it.

Link to comment
Share on other sites

Your systems boot fine because AMI Aptio 4 ships with DataHub... not even AMI is junk enough to not include DataHub. :P

DataHub cannot fix allocation errors. I had asked for a memory map before (privately) and got no response... with nothing to work with, legacy is the only 100% solution.

  • Like 5
Link to comment
Share on other sites

Your systems boot fine because AMI Aptio 4 ships with DataHub... not even AMI is junk enough to not include DataHub. :P

DataHub cannot fix allocation errors. I had asked for a memory mao before (privately) and got no response... with nothing to work with, legacy is the only 100% solution.

I assume you mean "memory map". Do you have any information on how to collect a memory map, and what we are looking for in it?

Link to comment
Share on other sites

One can dump it via 'memmap > fsX:\memmap.txt' (UEFI Shell).

One needs to find a block of free memory large enough for the kernel space, below 4GB.

Thanks... I'll do some experimentation on my systems that can run the UEFI shell (it crashes/hangs on some...)

Link to comment
Share on other sites

Thanks... I'll do some experimentation on my systems that can run the UEFI shell (it crashes/hangs on some...)

 

Huh? What's there to experiment, I thought your booting was fine?

I was refering to crusher' issue, if that wasn't clear.

Link to comment
Share on other sites

Huh? What's there to experiment, I thought your booting was fine?

I was refering to crusher' issue, if that wasn't clear.

I just want to see what the map looks like on my various systems... And see if the system will boot with CsrActiveConfig=0x03 (or values other than 0x67) without stopping on allocation errors in OsxAptioFix. Maybe there is some rhyme/reason...

Link to comment
Share on other sites

One can dump it via 'memmap > fsX:\memmap.txt' (UEFI Shell).

One needs to find a block of free memory large enough for the kernel space, below 4GB.

Here you go:

Type       Start            End               # Pages          Attributes
available  0000000000000000-0000000000057FFF  0000000000000058 000000000000000F
reserved   0000000000058000-0000000000058FFF  0000000000000001 000000000000000F
available  0000000000059000-000000000009DFFF  0000000000000045 000000000000000F
reserved   000000000009E000-000000000009FFFF  0000000000000002 000000000000000F
available  0000000000100000-000000000FFFFFFF  000000000000FF00 000000000000000F
BS_code    0000000010000000-000000001000AFFF  000000000000000B 000000000000000F
available  000000001000B000-0000000096FB2FFF  0000000000086FA8 000000000000000F
BS_data    0000000096FB3000-0000000096FF2FFF  0000000000000040 000000000000000F
available  0000000096FF3000-000000009DAD7FFF  0000000000006AE5 000000000000000F
LoaderData 000000009DAD8000-000000009DAFDFFF  0000000000000026 000000000000000F
LoaderCode 000000009DAFE000-000000009DBCAFFF  00000000000000CD 000000000000000F
BS_data    000000009DBCB000-000000009EABBFFF  0000000000000EF1 000000000000000F
RT_data    000000009EABC000-000000009EF9CFFF  00000000000004E1 800000000000000F
BS_data    000000009EF9D000-000000009EFA2FFF  0000000000000006 000000000000000F
available  000000009EFA3000-000000009EFA3FFF  0000000000000001 000000000000000F
LoaderData 000000009EFA4000-000000009EFB1FFF  000000000000000E 000000000000000F
BS_data    000000009EFB2000-00000000A2493FFF  00000000000034E2 000000000000000F
available  00000000A2494000-00000000A27BAFFF  0000000000000327 000000000000000F
BS_code    00000000A27BB000-00000000A2A93FFF  00000000000002D9 000000000000000F
reserved   00000000A2A94000-00000000A2AF4FFF  0000000000000061 000000000000000F
available  00000000A2AF5000-00000000A3314FFF  0000000000000820 000000000000000F
ACPI_NVS   00000000A3315000-00000000A4456FFF  0000000000001142 000000000000000F
RT_data    00000000A4457000-00000000A4EE3FFF  0000000000000A8D 800000000000000F
RT_code    00000000A4EE4000-00000000A4FFDFFF  000000000000011A 800000000000000F
BS_data    00000000A4FFE000-00000000A4FFEFFF  0000000000000001 000000000000000F
available  0000000100000000-00000001575FFFFF  0000000000057600 000000000000000F
reserved   00000000A5800000-00000000A79FFFFF  0000000000002200 0000000000000000
MemMapIO   00000000F8000000-00000000FBFFFFFF  0000000000004000 8000000000000001
MemMapIO   00000000FEC00000-00000000FEC00FFF  0000000000000001 8000000000000001
MemMapIO   00000000FED00000-00000000FED03FFF  0000000000000004 8000000000000001
MemMapIO   00000000FED1C000-00000000FED1FFFF  0000000000000004 8000000000000001
MemMapIO   00000000FEE00000-00000000FEE00FFF  0000000000000001 8000000000000001
MemMapIO   00000000FF000000-00000000FFFFFFFF  0000000000001000 8000000000000001

  reserved  :   8,804 Pages (36,061,184)
  LoaderCode:     205 Pages (839,680)
  LoaderData:      52 Pages (212,992)
  BS_code   :     740 Pages (3,031,040)
  BS_data   :  17,434 Pages (71,409,664)
  RT_code   :     282 Pages (1,155,072)
  RT_data   :   3,950 Pages (16,179,200)
  available : 1,006,450 Pages (4,122,419,200)
  ACPI_NVS  :   4,418 Pages (18,096,128)
  MemMapIO  :  20,490 Pages (83,927,040)
Total Memory: 4,037 MB (4,233,342,976) Bytes

http://pastebin.com/EVFLN8bQ

Link to comment
Share on other sites

I just want to see what the map looks like on my various systems... And see if the system will boot with CsrActiveConfig=0x03 (or values other than 0x67) without stopping on allocation errors in OsxAptioFix. Maybe there is some rhyme/reason...

 

For some odd reason, some more stuff is allocated high when CSR is not off.

 

@crusher

 

The relevant part is (<4GB):

Type       Start            End               # Pages          Attributes
available  0000000000000000-0000000000057FFF  0000000000000058 000000000000000F
reserved   0000000000058000-0000000000058FFF  0000000000000001 000000000000000F
available  0000000000059000-000000000009DFFF  0000000000000045 000000000000000F
reserved   000000000009E000-000000000009FFFF  0000000000000002 000000000000000F
available  0000000000100000-000000000FFFFFFF  000000000000FF00 000000000000000F
BS_code    0000000010000000-000000001000AFFF  000000000000000B 000000000000000F
available  000000001000B000-0000000096FB2FFF  0000000000086FA8 000000000000000F
BS_data    0000000096FB3000-0000000096FF2FFF  0000000000000040 000000000000000F
available  0000000096FF3000-000000009DAD7FFF  0000000000006AE5 000000000000000F
LoaderData 000000009DAD8000-000000009DAFDFFF  0000000000000026 000000000000000F
LoaderCode 000000009DAFE000-000000009DBCAFFF  00000000000000CD 000000000000000F
BS_data    000000009DBCB000-000000009EABBFFF  0000000000000EF1 000000000000000F
RT_data    000000009EABC000-000000009EF9CFFF  00000000000004E1 800000000000000F
BS_data    000000009EF9D000-000000009EFA2FFF  0000000000000006 000000000000000F
available  000000009EFA3000-000000009EFA3FFF  0000000000000001 000000000000000F
LoaderData 000000009EFA4000-000000009EFB1FFF  000000000000000E 000000000000000F
BS_data    000000009EFB2000-00000000A2493FFF  00000000000034E2 000000000000000F
available  00000000A2494000-00000000A27BAFFF  0000000000000327 000000000000000F
BS_code    00000000A27BB000-00000000A2A93FFF  00000000000002D9 000000000000000F
reserved   00000000A2A94000-00000000A2AF4FFF  0000000000000061 000000000000000F
available  00000000A2AF5000-00000000A3314FFF  0000000000000820 000000000000000F
ACPI_NVS   00000000A3315000-00000000A4456FFF  0000000000001142 000000000000000F
RT_data    00000000A4457000-00000000A4EE3FFF  0000000000000A8D 800000000000000F
RT_code    00000000A4EE4000-00000000A4FFDFFF  000000000000011A 800000000000000F
BS_data    00000000A4FFE000-00000000A4FFEFFF  0000000000000001 000000000000000F
available  0000000100000000-00000001575FFFFF  0000000000057600 000000000000000F

Comparing the error displayed with your memory map:

 

requested 000000000CA6D000-000000000CA7309E 000000000000609E 000000000000000F

available   0000000000100000-000000000FFFFFFF  000000000000FF00 000000000000000F

 

What is requested has a start address bigger than the beginning of the available block and an ending address smaller than the end of the free block. That means the memory boot.efi requested should actually fit into your memory map - and as it obviously doesn't, it means something being done between Clover GUI and boot.efi allocates that area.

 

What happens when booting with slide=0?

  • Like 1
Link to comment
Share on other sites

For some odd reason, some more stuff is allocated high when CSR is not off.

 

@crusher

 

The relevant part is (<4GB):

Type       Start            End               # Pages          Attributes
available  0000000000000000-0000000000057FFF  0000000000000058 000000000000000F
reserved   0000000000058000-0000000000058FFF  0000000000000001 000000000000000F
available  0000000000059000-000000000009DFFF  0000000000000045 000000000000000F
reserved   000000000009E000-000000000009FFFF  0000000000000002 000000000000000F
available  0000000000100000-000000000FFFFFFF  000000000000FF00 000000000000000F
BS_code    0000000010000000-000000001000AFFF  000000000000000B 000000000000000F
available  000000001000B000-0000000096FB2FFF  0000000000086FA8 000000000000000F
BS_data    0000000096FB3000-0000000096FF2FFF  0000000000000040 000000000000000F
available  0000000096FF3000-000000009DAD7FFF  0000000000006AE5 000000000000000F
LoaderData 000000009DAD8000-000000009DAFDFFF  0000000000000026 000000000000000F
LoaderCode 000000009DAFE000-000000009DBCAFFF  00000000000000CD 000000000000000F
BS_data    000000009DBCB000-000000009EABBFFF  0000000000000EF1 000000000000000F
RT_data    000000009EABC000-000000009EF9CFFF  00000000000004E1 800000000000000F
BS_data    000000009EF9D000-000000009EFA2FFF  0000000000000006 000000000000000F
available  000000009EFA3000-000000009EFA3FFF  0000000000000001 000000000000000F
LoaderData 000000009EFA4000-000000009EFB1FFF  000000000000000E 000000000000000F
BS_data    000000009EFB2000-00000000A2493FFF  00000000000034E2 000000000000000F
available  00000000A2494000-00000000A27BAFFF  0000000000000327 000000000000000F
BS_code    00000000A27BB000-00000000A2A93FFF  00000000000002D9 000000000000000F
reserved   00000000A2A94000-00000000A2AF4FFF  0000000000000061 000000000000000F
available  00000000A2AF5000-00000000A3314FFF  0000000000000820 000000000000000F
ACPI_NVS   00000000A3315000-00000000A4456FFF  0000000000001142 000000000000000F
RT_data    00000000A4457000-00000000A4EE3FFF  0000000000000A8D 800000000000000F
RT_code    00000000A4EE4000-00000000A4FFDFFF  000000000000011A 800000000000000F
BS_data    00000000A4FFE000-00000000A4FFEFFF  0000000000000001 000000000000000F
available  0000000100000000-00000001575FFFFF  0000000000057600 000000000000000F

Comparing the error displayed with your memory map:

 

requested 000000000CA6D000-000000000CA7309E 000000000000609E 000000000000000F

available   0000000000100000-000000000FFFFFFF  000000000000FF00 000000000000000F

 

What is requested has a start address bigger than the beginning of the available block and an ending address smaller than the end of the free block. That means the memory boot.efi requested should actually fit into your memory map - and as it obviously doesn't, it means something being done between Clover GUI and boot.efi allocates that area.

 

What happens when booting with slide=0?

I dont put any boot-args. I try with with csr-active 0x67 and 0x7F. Now I going to try with 0x43 and with slide=0

Link to comment
Share on other sites

just a question please. I'm new to Clover having used chameleon since starting the Hackintosh path. I'm using an AMD system as well and hardly anyone in this side uses Clover. as such, there's more guides/tips that uses Chameleon.

 

I will be setting up an Intel-based setup later today and I'm been reading various guides on how to make a USB installer. What I don't get is what happens next after I installed OSB using the USB installer?

 

On Chameleon, these are the steps I used:

 

1. boot into USB installer

2. install OS X

3. reboot

4. boot into USB installer but select OS X main drive on the available drives

5. install and setup chameleon

 

I would like to know if the post-installation steps are similar in Clover. Thank you very much

Link to comment
Share on other sites

Someone has working DumpUefiCalls.efi? I seems lost something. All my versions just hangs on black screen.

I want to see what news with ElCapitan here.

I pulled the latest DumpUeficalls.efi from my last compile of Clover (r3436) and it works fine.

 

If you still need it: DumpUefiCalls.efi.zip

Link to comment
Share on other sites

×
×
  • Create New...