Archi ICN Posted December 23, 2015 Share Posted December 23, 2015 To get rid of the early centered messages such as "Welcome to Clover" and others, I added option config.plist/Boot/NoEarlyProgress. Default false, but set to true, will eliminate these messages and result in a cleaner startup. Speedy-OSX:Clover RehabMan$ svn diff Index: rEFIt_UEFI/Platform/Settings.c =================================================================== --- rEFIt_UEFI/Platform/Settings.c (revision 3295) +++ rEFIt_UEFI/Platform/Settings.c (working copy) @@ -1830,6 +1830,11 @@ GlobalConfig.FastBoot = TRUE; } + Prop = GetProperty (DictPointer, "NoEarlyProgress"); + if (IsPropertyTrue (Prop)) { + GlobalConfig.NoEarlyProgress = TRUE; + } + Prop = GetProperty (DictPointer, "NeverHibernate"); if (IsPropertyTrue (Prop)) { GlobalConfig.NeverHibernate = TRUE; Index: rEFIt_UEFI/refit/lib.h =================================================================== --- rEFIt_UEFI/refit/lib.h (revision 3295) +++ rEFIt_UEFI/refit/lib.h (working copy) @@ -435,6 +435,7 @@ INTN TileXSpace; INTN TileYSpace; BOOLEAN Proportional; + BOOLEAN NoEarlyProgress; } REFIT_CONFIG; // types Index: rEFIt_UEFI/refit/main.c =================================================================== --- rEFIt_UEFI/refit/main.c (revision 3295) +++ rEFIt_UEFI/refit/main.c (working copy) @@ -2032,7 +2032,7 @@ return Status; } // DBG("DBG: messages\n"); - if (!GlobalConfig.FastBoot && GlobalConfig.Timeout>0) { + if (!GlobalConfig.NoEarlyProgress && !GlobalConfig.FastBoot && GlobalConfig.Timeout>0) { FirstMessage = PoolPrint(L" Welcome to Clover %s ", FIRMWARE_REVISION); i = (UGAWidth - StrLen(FirstMessage) * GlobalConfig.CharWidth) >> 1; DrawTextXY(FirstMessage, i, UGAHeight >> 1, X_IS_CENTER); @@ -2075,7 +2075,7 @@ gCPUStructure.ExternalClock = (UINT32)DivU64x32(gCPUStructure.FSBFrequency, kilo); gCPUStructure.MaxSpeed = (UINT32)DivU64x32(gCPUStructure.TSCFrequency + (Mega >> 1), Mega); - if (!GlobalConfig.FastBoot && GlobalConfig.Timeout>0) { + if (!GlobalConfig.NoEarlyProgress && !GlobalConfig.FastBoot && GlobalConfig.Timeout>0) { FirstMessage = PoolPrint(L"... user settings ..."); i = (UGAWidth - StrLen(FirstMessage) * GlobalConfig.CharWidth) >> 1; DrawTextXY(FirstMessage, i, (UGAHeight >> 1) + 20, X_IS_CENTER); @@ -2141,7 +2141,7 @@ GetEfiBootDeviceFromNvram(); } - if (!GlobalConfig.FastBoot && GlobalConfig.Timeout>0) { + if (!GlobalConfig.NoEarlyProgress && !GlobalConfig.FastBoot && GlobalConfig.Timeout>0) { FirstMessage = PoolPrint(L"... scan entries ..."); i = (UGAWidth - StrLen(FirstMessage) * GlobalConfig.CharWidth) >> 1; DrawTextXY(FirstMessage, i, (UGAHeight >> 1) + 20, X_IS_CENTER); @@ -2230,7 +2230,7 @@ AddMenuEntry(&MainMenu, &MenuEntryShutdown); } - if (GlobalConfig.Timeout>0) { + if (!GlobalConfig.NoEarlyProgress && !GlobalConfig.FastBoot && GlobalConfig.Timeout>0) { FirstMessage = PoolPrint(L"...theme %s ...", GlobalConfig.Theme); i = (UGAWidth - StrLen(FirstMessage) * GlobalConfig.CharWidth) >> 1; DrawTextXY(FirstMessage, i, (UGAHeight >> 1) + 20, X_IS_CENTER); Note: I'm pretty sure that last one was lacking the test for !GlobalConfig.FastBoot, so I fixed it. Thank you very much it helped me get rid of the the problems with messages. now everything works just. Link to comment Share on other sites More sharing options...
Micky1979 Posted December 28, 2015 Share Posted December 28, 2015 I had the same problem some time ago and got out by to rebuild "PrelinkToKernel" and cache sudo kextcache -system-prelinked-kernel sudo kextcache -system-caches PrelinkToKernel.app only extract the kernel from prelinkedkernel/kernelcache, maybe the good idea was to rebuilt the cache only Link to comment Share on other sites More sharing options...
Slice Posted December 29, 2015 Share Posted December 29, 2015 What is the situation when you need to rebuild kernelcache? Let OS do the work! Link to comment Share on other sites More sharing options...
Micky1979 Posted January 4, 2016 Share Posted January 4, 2016 What is the situation when you need to rebuild kernelcache? Let OS do the work! After accessing /System/Library/Extensions. Only in 10.10+ the cache is auto-updated, otherwise in older OSes the kernelcache became older then SLE and will never be used (at least until the timestamp is updated). We still use old 10.7-10.9 too Link to comment Share on other sites More sharing options...
Slice Posted January 5, 2016 Share Posted January 5, 2016 After accessing /System/Library/Extensions. Only in 10.10+ the cache is auto-updated, otherwise in older OSes the kernelcache became older then SLE and will never be used (at least until the timestamp is updated). We still use old 10.7-10.9 too See my signature about used OSX versions. 1 Link to comment Share on other sites More sharing options...
Micky1979 Posted January 5, 2016 Share Posted January 5, 2016 See my signature about used OSX versions. Yep, mee too (not like you but see mine). What say... In reality my main OS is always the latest and I use older ones only to made tests with programs/apps I made to ensure compatibility (or often made by others), so probably you have right and I play too much with OSes ... but in truth it's fun, so sometimes I have to do extra steps BTW I consider OSes < 10.7 very old because Apple made radically changes (like the obj-c runtime 2.x in witch the OS is actually made since lion) in a way that is not easy or impossible to maintain compatibility with some old softwares (not the case of a bootloader anyway). IMHO is sign to change the starting supported OS from 10.7 to slim some codes (look here) Link to comment Share on other sites More sharing options...
mhaeuser Posted January 5, 2016 Share Posted January 5, 2016 No need to drop support, conditional compilation is the way to go imo. 1 Link to comment Share on other sites More sharing options...
Micky1979 Posted January 5, 2016 Share Posted January 5, 2016 No need to drop support, conditional compilation is the way to go imo. Yep, that's why I said "IMHO", different thought... Link to comment Share on other sites More sharing options...
Slice Posted January 5, 2016 Share Posted January 5, 2016 10.6.8 is the last system for 32bit only CPU like Yonah. 10.7.5 is the last system for Geforce7xxx and GMA950, they are 32bit only GPU. 10.8.3 is the first system with good Radeon drivers. 10.9.5 IMHO is the last good system. Anyway for new hardware there new system needed. 1 Link to comment Share on other sites More sharing options...
mhaeuser Posted January 5, 2016 Share Posted January 5, 2016 Lion still had 32-bit EFI and 32-bit kernel support, no? Link to comment Share on other sites More sharing options...
Slice Posted January 6, 2016 Share Posted January 6, 2016 Lion still had 32-bit EFI and 32-bit kernel support, no? Yes, but it uses 64bit codes somewhere (finder, loginwindow). 1 Link to comment Share on other sites More sharing options...
jan4321 Posted January 12, 2016 Share Posted January 12, 2016 Noticed a bug in Clover_v2.3k_r3330 while patching my DSDT. With FixRegions = true a value is set to 0x00. Below is the diff between the disassemblies of CLOVER/ACPI/patched/DSDT.aml and an patchmatic extract on the running system. The SMIB value is set to 0x00. With FixRegions = false this is left untouched. $ diff in/DSDT.dsl out/DSDT.dsl 8c8 < * Disassembly of DSDT.aml, Tue Jan 12 23:07:08 2016 --- > * Disassembly of DSDT.aml, Tue Jan 12 23:07:15 2016 14,15c14,15 < * Checksum 0xD6 < * OEM ID "DELL " --- > * Checksum 0xDC > * OEM ID "Apple " 21c21 < DefinitionBlock ("DSDT.aml", "DSDT", 2, "DELL ", "CBX3 ", 0x00000021) --- > DefinitionBlock ("DSDT.aml", "DSDT", 2, "Apple ", "CBX3 ", 0x00000021) 7913c7913 < Name (SMIB, 0xDA7D6000) --- > Name (SMIB, 0x00000000) Attached fixregionsbug.zip contains the DSDT from CLOVER/ACPI/patched in the "in" folder and the patchmatic extract in the "out" folder. Link to comment Share on other sites More sharing options...
Slice Posted January 13, 2016 Share Posted January 13, 2016 I don't think this is a Clover bug. It is expected BIOS behavior. See method If (LEqual (SMIB, Zero)) { \RMDT.PUSH ("SNVC patch SMIB value") Store (0xDA7D6000, SMIB) } Clover write 0 because it found zero in BIOS. The value 0xDA7D6000 appears here later. Link to comment Share on other sites More sharing options...
RehabMan Posted January 13, 2016 Share Posted January 13, 2016 I don't think this is a Clover bug. It is expected BIOS behavior. See method If (LEqual (SMIB, Zero)) { \RMDT.PUSH ("SNVC patch SMIB value") Store (0xDA7D6000, SMIB) } Clover write 0 because it found zero in BIOS. The value 0xDA7D6000 appears here later. The native DSDT in this case does not have zero. Clover F4 extract to ACPI/origin shows it initialized to 0xDA7D6000. The code you're reading above is a patch put in the file to correct the issue caused by the Clover bug. Something is wrong here. Link to comment Share on other sites More sharing options...
RehabMan Posted January 15, 2016 Share Posted January 15, 2016 Noticed a bug in Clover_v2.3k_r3330 while patching my DSDT. With FixRegions = true a value is set to 0x00. Below is the diff between the disassemblies of CLOVER/ACPI/patched/DSDT.aml and an patchmatic extract on the running system. The SMIB value is set to 0x00. With FixRegions = false this is left untouched. $ diff in/DSDT.dsl out/DSDT.dsl 8c8 < * Disassembly of DSDT.aml, Tue Jan 12 23:07:08 2016 --- > * Disassembly of DSDT.aml, Tue Jan 12 23:07:15 2016 14,15c14,15 < * Checksum 0xD6 < * OEM ID "DELL " --- > * Checksum 0xDC > * OEM ID "Apple " 21c21 < DefinitionBlock ("DSDT.aml", "DSDT", 2, "DELL ", "CBX3 ", 0x00000021) --- > DefinitionBlock ("DSDT.aml", "DSDT", 2, "Apple ", "CBX3 ", 0x00000021) 7913c7913 < Name (SMIB, 0xDA7D6000) --- > Name (SMIB, 0x00000000) Attached fixregionsbug.zip contains the DSDT from CLOVER/ACPI/patched in the "in" folder and the patchmatic extract in the "out" folder. Posting native DSDT.aml from ACPI/origin (press F4 in Clover) would be helpful in finding the Clover bug here. Link to comment Share on other sites More sharing options...
jan4321 Posted January 20, 2016 Share Posted January 20, 2016 Posting native DSDT.aml from ACPI/origin (press F4 in Clover) would be helpful in finding the Clover bug here. origin.zip Link to comment Share on other sites More sharing options...
RehabMan Posted January 20, 2016 Share Posted January 20, 2016 origin.zip Can you post a Clover bootlog with the FixRegions option enabled? Edit: I'm pretty sure I see the bug... Edit 2: Yes, definitely found the bug. I'll provide a patch later today... 1 Link to comment Share on other sites More sharing options...
RehabMan Posted January 21, 2016 Share Posted January 21, 2016 Edit 2: Yes, definitely found the bug. I'll provide a patch later today...Definitely a bug in Clover. Here is explanation and fix... This FixRegions option consists of two functions in FixBiosDsdt.c: GetBiosRegions and FixRegions. GetBiosRegions builds a linked list of OperationRegion of type SystemMemory from native DSDT. Captured in this list is the name of the region and the address. If the address is indirect, then the address of the indirect Name is captured (if possible). FixRegions applies the addresses captured by GetBiosRegions to the patched DSDT by matching each region by name. The problem posed in this DSDT is that there are a total of three SystemMemory regions named WWPR, each in a separate method scope. Clover's DSDT patcher knows nothing about scope. Here is the related DSDT code snips: Method (SNVC, 1, NotSerialized) { OperationRegion (WWPR, SystemMemory, SMIB, 0x04) ... } Method (SNWB, 2, NotSerialized) { Store (SMIB, Local0) Add (Local0, Arg1, Local0) Add (Local0, 0x04, Local0) OperationRegion (WWPR, SystemMemory, Local0, One) ... } Method (SNRB, 2, NotSerialized) { Store (SMIB, Local0) Add (Local0, Arg1, Local0) Add (Local0, 0x04, Local0) OperationRegion (WWPR, SystemMemory, Local0, 0x04) ... } The OperationRegion definitions in SNWB and SNRB use Local0. As one might expect, in this case Clover cannot determine how to capture the address because it is a runtime value (Local0). But still, the code captures the region in the linked list of regions (gRegions) with a zero address. Because FixRegions looks at the list in order, and the entries added last appear in the list first, it is the entry for WWPR with a zero address that is used to "fix" the first WWPR OperationRegion in SNVC (by modifying the value for SMIB). The fix is to not add OperationRegion definitions to the gRegions list where the address cannot be determined. The fixed GetBiosRegions: VOID GetBiosRegions(EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE* fadt) { EFI_ACPI_DESCRIPTION_HEADER *TableHeader; UINT8 *buffer = NULL; UINT32 bufferLen = 0; UINTN i, j; INTN shift, shift2; CHAR8 Name[8]; CHAR8 NameAdr[8]; gRegions = NULL; buffer = (UINT8*)(UINTN)fadt->Dsdt; TableHeader = (EFI_ACPI_DESCRIPTION_HEADER*)buffer; bufferLen = TableHeader->Length; for (i=0x24; i<bufferLen-15; i++) { if ((buffer[i] == 0x5B) && (buffer[i+1] == 0x80) && GetName(buffer, (INT32)(i+2), &Name[0], &shift)) { if (buffer[i+6+shift] == 0) { //this is SystemMemory region. Write to bios regions tables OPER_REGION tmp; tmp.Address = 0; CopyMem(&tmp.Name[0], &buffer[i+2+shift], 4); tmp.Name[4] = 0; if (buffer[i+7+shift] == 0x0C) { CopyMem(&tmp.Address, &buffer[i+8+shift], 4); } else if (buffer[i+7+shift] == 0x0B) { CopyMem(&tmp.Address, &buffer[i+8+shift], 2); } else if (GetName(buffer, (INT32)(i+7+shift), &NameAdr[0], &shift2)) { j = FindName(buffer, bufferLen, &NameAdr[0]); if (j > 0) { if (buffer[j+4] == 0x0C) { CopyMem(&tmp.Address, &buffer[j+5], 4); } else if (buffer[j+4] == 0x0B) { CopyMem(&tmp.Address, &buffer[j+5], 2); } } } if (!tmp.Address) { DBG("Unable to determine address for OperationRegion(%a, SystemMemory, ...) skipping\n", tmp.Name); // ignore OperationRegion where the address cannot be determined continue; } DBG("Found OperationRegion(%a, SystemMemory, %x, ...)\n", tmp.Name, tmp.Address); OPER_REGION *newRegion = AllocateZeroPool(sizeof(OPER_REGION)); *newRegion = tmp; newRegion->next = gRegions; gRegions = newRegion; } } } } Note: Some fixes there to make the debug output a bit more useful too... I would also suggest a few other changes... No need to call GetBiosRegions when it is known that FixRegions will not be called: Index: rEFIt_UEFI/Platform/AcpiPatcher.c =================================================================== --- rEFIt_UEFI/Platform/AcpiPatcher.c (revision 3333) +++ rEFIt_UEFI/Platform/AcpiPatcher.c (working copy) @@ -1654,8 +1654,11 @@ } //Get regions from BIOS DSDT - GetBiosRegions(FadtPointer); - + if (((gSettings.FixDsdt & FIX_WARNING) && !(gSettings.FixDsdt & FIX_NEW_WAY)) || + ((gSettings.FixDsdt & FIX_NEW_WAY) && (gSettings.FixDsdt & FIX_REGIONS))) { + GetBiosRegions(FadtPointer); + } + // DBG("DSDT finding\n"); if (!Volume) { DBG("Volume not found!\n"); And it is nice to know which regions are actually being changed (vs. those that were already correct): --- rEFIt_UEFI/Platform/FixBiosDsdt.c (revision 3333) +++ rEFIt_UEFI/Platform/FixBiosDsdt.c (working copy) @@ -4827,10 +4827,13 @@ p = gRegions; while (p) { if (AsciiStrStr(p->Name, Name)) { + UINT32 oldAddress = 0; //apply patch if (dsdt[i+7+shift] == 0x0C) { + CopyMem(&oldAddress, &dsdt[i+8+shift], 4); CopyMem(&dsdt[i+8+shift], &p->Address, 4); } else if (dsdt[i+7+shift] == 0x0B) { + CopyMem(&oldAddress, &dsdt[i+8+shift], 2); CopyMem(&dsdt[i+8+shift], &p->Address, 2); } else { //propose this is indirect name @@ -4839,9 +4842,11 @@ if (j > 0) { DBG(" indirect name=%a\n", NameAdr); if (dsdt[j+4] == 0x0C) { + CopyMem(&oldAddress, &dsdt[j+5], 4); CopyMem(&dsdt[j+5], &p->Address, 4); // Corrected = TRUE; } else if (dsdt[j+4] == 0x0B) { + CopyMem(&oldAddress, &dsdt[j+5], 2); CopyMem(&dsdt[j+5], &p->Address, 2); } else { DBG("... value not defined\n"); @@ -4849,7 +4854,9 @@ } } } - DBG("OperationRegion (%a...) corrected to addr=0x%x\n", Name, p->Address); + if (oldAddress != p->Address) { + DBG("OperationRegion (%a...) corrected to addr=0x%x\n", Name, p->Address); + } break; } p = p->next; Note that the code still can cause problems. Since it is matching addresses by OperationRegion name, you can run into issues if multiple OperationRegion declarations use the same name. For example: Method(FOO) { OperationRegion (ORSM, SystemMemory, 0xDA7FFF18, 0x000D) } Method(BAR) { OperationRegion (ORSM, SystemMemory, 0xFA700018, 0x000D) } In this case, the FixRegions code will "fix" FOO.ORSM with the address from BAR.ORSM. It is legal ACPI code, but because Clover doesn't understand the concept of scope here, you get incorrect results. Something like that is probably rare, but still an issue to be aware of. 3 Link to comment Share on other sites More sharing options...
Slice Posted January 21, 2016 Share Posted January 21, 2016 Thanks RehabMan, committed! 1 Link to comment Share on other sites More sharing options...
Needy Posted March 4, 2016 Share Posted March 4, 2016 Boot log: 1:102 0:000 Clover revision: 3346 running on P31-DS3L 1:102 0:000 ... with board P31-DS3L 1:102 0:000 CPU Vendor = 756E6547 Model=10676 1:102 0:000 The CPU not supported turbo 1:102 0:000 BrandString = Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz 1:102 0:000 MSR dumps: 1:102 0:000 @0x00CD=804 1:102 0:000 @0x0198=61A082006040620 1:102 0:000 FSBFrequency=666MHz DMIvalue=333330kHz 1:102 0:000 Corrected FSBFrequency=333MHz 1:102 0:000 Vendor/Model/Stepping: 0x756E6547/0x17/0x6 1:102 0:000 Family/ExtFamily: 0x6/0x0 1:102 0:000 MaxDiv/MinDiv: 6.0/6 1:102 0:000 Turbo: 7/0/0/0 1:102 0:000 Features: 0xBFEBFBFF 1:102 0:000 Threads: 2 1:102 0:000 Cores: 1 1:102 0:000 FSB: 333 MHz 1:102 0:000 CPU: 4000 MHz 1:102 0:000 TSC: 4000 MHz 1:102 0:000 PIS: 1333 MHz It is not DSDT error. It is BIOS bug. Please make AIDA64 report (CPU part) and report to Clover thread. Here's the report: --------[ CPU ]--------------------------------------------------------------------------------------------------------- CPU Properties: CPU Type DualCore Intel Core 2 Duo E8200, 2000 MHz (6 x 333) CPU Alias Wolfdale CPU Stepping C0 Instruction Set x86, x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 Original Clock 2667 MHz Min / Max CPU Multiplier 6x / 8x Engineering Sample No L1 Code Cache 32 KB per core L1 Data Cache 32 KB per core L2 Cache 6 MB (On-Die, ECC, ASC, Full-Speed) CPU Physical Info: Package Type 775 Contact FC-LGA8 Package Size 37.5 mm x 37.5 mm Transistors 410 million Process Technology 45 nm, CMOS, Cu, High-K + Metal Gate Die Size 107 mm2 Core Voltage 1.150 - 1.225 V I/O Voltage 1.150 - 1.225 V Typical Power 65 W @ 2.66 GHz Maximum Power 91.9 W @ 2.66 GHz CPU Manufacturer: Company Name Intel Corporation Product Information http://ark.intel.com/search.aspx?q=Intel%20Core%202%20Duo%20E8200 Driver Update http://www.aida64.com/driver-updates Multi CPU: Motherboard ID OEM00000 PROD00000000 CPU #1 Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz, 2667 MHz CPU #2 Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz, 2667 MHz CPU Utilization: CPU #1 / Core #1 0% CPU #1 / Core #2 0% --------[ CPUID ]------------------------------------------------------------------------------------------------------- CPUID Properties: CPUID Manufacturer GenuineIntel CPUID CPU Name Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz CPUID Revision 00010676h IA Brand ID 00h (Unknown) Platform ID 3Dh / MC 01h (LGA775) Microcode Update Revision 610h HTT / CMP Units 0 / 2 Tjmax Temperature 100 ∞C (212 ∞F) CPU Thermal Design Power 65 W Instruction Set: 64-bit x86 Extension (AMD64, Intel64) Supported AMD 3DNow! Not Supported AMD 3DNow! Professional Not Supported AMD 3DNowPrefetch Not Supported AMD Enhanced 3DNow! Not Supported AMD Extended MMX Not Supported AMD FMA4 Not Supported AMD MisAligned SSE Not Supported AMD SSE4A Not Supported AMD XOP Not Supported Cyrix Extended MMX Not Supported Enhanced REP MOVSB/STOSB Not Supported Float-16 Conversion Instructions Not Supported IA-64 Not Supported IA AES Extensions Not Supported IA AVX Not Supported IA AVX2 Not Supported IA AVX-512 (AVX512F) Not Supported IA AVX-512 52-bit Integer Instructions (AVX512IFMA52)Not Supported IA AVX-512 Byte and Word Instructions (AVX512BW) Not Supported IA AVX-512 Conflict Detection Instructions (AVX512CD)Not Supported IA AVX-512 Doubleword and Quadword Instructions (AVX512DQ)Not Supported IA AVX-512 Exponential and Reciprocal Instructions (AVX512ER)Not Supported IA AVX-512 Prefetch Instructions (AVX512PF) Not Supported IA AVX-512 Vector Bit Manipulation Instructions (AVX512VBMI)Not Supported IA AVX-512 Vector Length Extensions (AVX512VL) Not Supported IA BMI1 Not Supported IA BMI2 Not Supported IA FMA Not Supported IA MMX Supported IA SHA Extensions Not Supported IA SSE Supported IA SSE2 Supported IA SSE3 Supported IA Supplemental SSE3 Supported IA SSE4.1 Supported IA SSE4.2 Not Supported VIA Alternate Instruction Set Not Supported ADCX / ADOX Instruction Not Supported CLFLUSH Instruction Supported CLFLUSHOPT Instruction Not Supported CLWB Instruction Not Supported CMPXCHG8B Instruction Supported CMPXCHG16B Instruction Supported Conditional Move Instruction Supported INVPCID Instruction Not Supported LAHF / SAHF Instruction Supported LZCNT Instruction Not Supported MONITOR / MWAIT Instruction Supported MONITORX / MWAITX Instruction Not Supported MOVBE Instruction Not Supported PCLMULQDQ Instruction Not Supported PCOMMIT Instruction Not Supported POPCNT Instruction Not Supported PREFETCHWT1 Instruction Not Supported RDFSBASE / RDGSBASE / WRFSBASE / WRGSBASE InstructionNot Supported RDRAND Instruction Not Supported RDSEED Instruction Not Supported RDTSCP Instruction Not Supported SKINIT / STGI Instruction Not Supported SYSCALL / SYSRET Instruction Not Supported SYSENTER / SYSEXIT Instruction Supported Trailing Bit Manipulation Instructions Not Supported VIA FEMMS Instruction Not Supported Security Features: Advanced Cryptography Engine (ACE) Not Supported Advanced Cryptography Engine 2 (ACE2) Not Supported Data Execution Prevention (DEP, NX, EDB) Supported Hardware Random Number Generator (RNG) Not Supported Hardware Random Number Generator 2 (RNG2) Not Supported Memory Protection Extensions (MPX) Not Supported PadLock Hash Engine (PHE) Not Supported PadLock Hash Engine 2 (PHE2) Not Supported PadLock Montgomery Multiplier (PMM) Not Supported PadLock Montgomery Multiplier 2 (PMM2) Not Supported Processor Serial Number (PSN) Not Supported Safer Mode Extensions (SMX) Supported Software Guard Extensions (SGX) Not Supported Supervisor Mode Access Prevention (SMAP) Not Supported Supervisor Mode Execution Protection (SMEP) Not Supported Power Management Features: Application Power Management (APM) Not Supported Automatic Clock Control Supported Core C6 State (CC6) Not Supported Digital Thermometer Supported Dynamic FSB Frequency Switching Not Supported Enhanced Halt State (C1E) Supported, Enabled Enhanced SpeedStep Technology (EIST, ESS) Supported, Enabled Frequency ID Control Not Supported Hardware P-State Control Not Supported Hardware Thermal Control (HTC) Not Supported LongRun Not Supported LongRun Table Interface Not Supported Overstress Not Supported Package C6 State (PC6) Not Supported Parallax Not Supported PowerSaver 1.0 Not Supported PowerSaver 2.0 Not Supported PowerSaver 3.0 Not Supported Processor Duty Cycle Control Supported Software Thermal Control Not Supported Temperature Sensing Diode Not Supported Thermal Monitor 1 Supported Thermal Monitor 2 Supported Thermal Monitor 3 Not Supported Thermal Monitoring Not Supported Thermal Trip Not Supported Voltage ID Control Not Supported Virtualization Features: Extended Page Table (EPT) Not Supported Hypervisor Not Present INVEPT Instruction Not Supported INVVPID Instruction Not Supported Nested Paging (NPT, RVI) Not Supported Secure Virtual Machine (SVM, Pacifica) Not Supported Virtual Machine Extensions (VMX, Vanderpool) Supported Virtual Processor ID (VPID) Not Supported CPUID Features: 1 GB Page Size Not Supported 36-bit Page Size Extension Supported 64-bit DS Area Supported Adaptive Overclocking Not Supported Address Region Registers (ARR) Not Supported Configurable TDP (cTDP) Not Supported Core Performance Boost (CPB) Not Supported Core Performance Counters Not Supported CPL Qualified Debug Store Supported Data Breakpoint Extension Not Supported Debug Trace Store Supported Debugging Extension Supported Deprecated FPU CS and FPU DS Not Supported Direct Cache Access Not Supported Dynamic Acceleration Technology (IDA) Not Supported Dynamic Configurable TDP (DcTDP) Not Supported Extended APIC Register Space Not Supported Fast Save & Restore Supported Hardware Lock Elision (HLE) Not Supported Hybrid Boost Not Supported Hyper-Threading Technology (HTT) Not Supported Instruction Based Sampling Not Supported Invariant Time Stamp Counter Supported L1 Context ID Not Supported L2I Performance Counters Not Supported Lightweight Profiling Not Supported Local APIC On Chip Supported Machine Check Architecture (MCA) Supported Machine Check Exception (MCE) Supported Memory Configuration Registers (MCR) Not Supported Memory Type Range Registers (MTRR) Supported Model Specific Registers (MSR) Supported NB Performance Counters Not Supported Page Attribute Table (PAT) Supported Page Global Extension Supported Page Size Extension (PSE) Supported Pending Break Event (PBE) Supported Performance Time Stamp Counter (PTSC) Not Supported Physical Address Extension (PAE) Supported Platform Quality of Service Enforcement (PQE) Not Supported Platform Quality of Service Monitoring (PQM) Not Supported Process Context Identifiers (PCID) Not Supported Processor Feedback Interface Not Supported Processor Trace (PT) Not Supported Restricted Transactional Memory (RTM) Not Supported Self-Snoop Supported Time Stamp Counter (TSC) Supported Turbo Boost Not Supported Virtual Mode Extension Supported Watchdog Timer Not Supported x2APIC Not Supported XGETBV / XSETBV OS Enabled Not Supported XSAVE / XRSTOR / XSETBV / XGETBV Extended States Not Supported XSAVEOPT Not Supported CPUID Registers (CPU #1): CPUID 00000000 0000000A-756E6547-6C65746E-49656E69 [GenuineIntel] CPUID 00000001 00010676-00020800-0008E3FD-BFEBFBFF CPUID 00000002 05B0B101-005657F0-00000000-2CB4304E CPUID 00000003 00000000-00000000-00000000-00000000 CPUID 00000004 04000121-01C0003F-0000003F-00000001 [SL 00] CPUID 00000004 04000122-01C0003F-0000003F-00000001 [SL 01] CPUID 00000004 04004143-05C0003F-00000FFF-00000001 [SL 02] CPUID 00000005 00000040-00000040-00000003-00022220 CPUID 00000006 00000001-00000002-00000001-00000000 CPUID 00000007 00000000-00000000-00000000-00000000 CPUID 00000008 00000400-00000000-00000000-00000000 CPUID 00000009 00000000-00000000-00000000-00000000 CPUID 0000000A 07280202-00000000-00000000-00000503 CPUID 80000000 80000008-00000000-00000000-00000000 CPUID 80000001 00000000-00000000-00000001-20100000 CPUID 80000002 65746E49-2952286C-726F4320-4D542865 [Intel(R) Core(TM] CPUID 80000003 44203229-43206F75-20205550-45202020 [)2 Duo CPU E] CPUID 80000004 30303238-20402020-36362E32-007A4847 [8200 @ 2.66GHz] CPUID 80000005 00000000-00000000-00000000-00000000 CPUID 80000006 00000000-00000000-18008040-00000000 CPUID 80000007 00000000-00000000-00000000-00000000 CPUID 80000008 00003024-00000000-00000000-00000000 CPUID Registers (CPU #2): CPUID 00000000 0000000A-756E6547-6C65746E-49656E69 [GenuineIntel] CPUID 00000001 00010676-01020800-0008E3FD-BFEBFBFF CPUID 00000002 05B0B101-005657F0-00000000-2CB4304E CPUID 00000003 00000000-00000000-00000000-00000000 CPUID 00000004 04000121-01C0003F-0000003F-00000001 [SL 00] CPUID 00000004 04000122-01C0003F-0000003F-00000001 [SL 01] CPUID 00000004 04004143-05C0003F-00000FFF-00000001 [SL 02] CPUID 00000005 00000040-00000040-00000003-00022220 CPUID 00000006 00000001-00000002-00000001-00000000 CPUID 00000007 00000000-00000000-00000000-00000000 CPUID 00000008 00000400-00000000-00000000-00000000 CPUID 00000009 00000000-00000000-00000000-00000000 CPUID 0000000A 07280202-00000000-00000000-00000503 CPUID 80000000 80000008-00000000-00000000-00000000 CPUID 80000001 00000000-00000000-00000001-20100000 CPUID 80000002 65746E49-2952286C-726F4320-4D542865 [Intel(R) Core(TM] CPUID 80000003 44203229-43206F75-20205550-45202020 [)2 Duo CPU E] CPUID 80000004 30303238-20402020-36362E32-007A4847 [8200 @ 2.66GHz] CPUID 80000005 00000000-00000000-00000000-00000000 CPUID 80000006 00000000-00000000-18008040-00000000 CPUID 80000007 00000000-00000000-00000000-00000000 CPUID 80000008 00003024-00000000-00000000-00000000 MSR Registers: MSR 00000017 0400-0000-8884-8820 [PlatID = 0] MSR 0000001B 0000-0000-FEE0-0900 MSR 0000002A 0000-0000-4188-0000 MSR 0000008B 0000-0610-0000-0000 MSR 000000CD 0000-0000-0000-0804 MSR 000000CE 001A-0820-1919-0717 MSR 000000E7 0000-0000-0002-EFC8 MSR 000000E7 0000-0000-0003-B6C8 [S200] MSR 000000E7 0000-0000-00BF-D9A0 [S200] MSR 000000E8 0000-0000-0000-A51E MSR 000000E8 0000-0000-0001-ED92 [S200] MSR 000000E8 0000-0000-0002-8524 [S200] MSR 000000EE 0000-0000-867D-1300 MSR 0000011E 0000-0000-BE70-2111 MSR 00000198 061A-0820-0604-061A MSR 00000198 061A-0820-0604-061A [S200] MSR 00000198 061A-0820-0604-061A [S200] MSR 00000199 0000-0000-0000-0820 MSR 0000019A 0000-0000-0000-0008 MSR 0000019B 0000-0000-0000-0000 MSR 0000019C 0000-0000-883F-000C MSR 0000019C 0000-0000-883F-000C [S200] MSR 0000019C 0000-0000-883F-000C [S200] MSR 0000019D 0000-0000-0000-061A MSR 000001A0 0000-0040-6287-2489 MSR 00000480 005A-0800-0000-000D MSR 00000481 0000-003F-0000-0016 MSR 00000482 F7F9-FFFE-0401-E172 MSR 00000483 0003-FFFF-0003-6DFF MSR 00000484 0000-3FFF-0000-11FF MSR 00000485 0000-0000-0004-03C0 MSR 00000486 0000-0000-8000-0021 MSR 00000487 0000-0000-FFFF-FFFF MSR 00000488 0000-0000-0000-2000 MSR 00000489 0000-0000-0000-67FF MSR 0000048A 0000-0000-0000-002C MSR 0000048B 0000-0041-0000-0000 Best regards. Link to comment Share on other sites More sharing options...
René_ Posted March 4, 2016 Share Posted March 4, 2016 Slice, maybe this can help too: http://www.insanelymac.com/forum/topic/302877-guide-yosemite-1010x-dell-optiplex-780-760/page-13?do=findComment&comment=2138529 Link to comment Share on other sites More sharing options...
Slice Posted March 4, 2016 Share Posted March 4, 2016 Yes, same problem with model 0x17.- Penryn, Wolfdale, Harpertown Test, please, rev 3357. I will upload it into "General Discussion". Link to comment Share on other sites More sharing options...
zhhbc Posted March 10, 2016 Share Posted March 10, 2016 Hi, I have El Capitan 10.11.2 installed on dell inspiron 5558 using clover bootloader. Everything seems work fine except, I couldn't update to latest release 10.11.3. After checking install.log, I think the problem is that "product-name", "model", and "compatible" are set to "Mac-189A3D4F9" ( as shown from ioreg -l) instead of "MacBookPro11,1", the one I set in config.plist under SMBIOS section. Further investigation shows that the root cause is the combination of how cloverefi updates smbios strings and the way smbios was created: For system information structure (type 1) in inspiron 15-5558 smbios, it uses the same string value for both ProductName and SKU Number, I guess it is a "smart" way to save a few bytes. So clover updates ProductName to MacBookPro11,1 first, but then the string is overwritten by SKU Number, which is "MAC-189A3D4F9", so the final result of ProductName becomes "MAC-189A3D4F9". I patched clover code, now it works, kind of. I still have one issue: if productname is more than 13 bytes, the bytes after 13th byte become spaces(0x20). so productname shows up as "MacBookPro11, " instead of "MacBookPro11,1". Besides PatchTableType1 function in smbios.c file, is there any other file updates value of SMBIOS? Thanks, Link to comment Share on other sites More sharing options...
Slice Posted March 10, 2016 Share Posted March 10, 2016 Only smbios.c file. We never saw such a bug. Link to comment Share on other sites More sharing options...
RehabMan Posted March 10, 2016 Share Posted March 10, 2016 Only smbios.c file. We never saw such a bug. It is actually pretty common with certain Broadwell laptops (not sure if it was all Dell or not)... Until now, we didn't know the cause... It does not look like the code in PatchTableType1 and UpdateSmbiosString contemplate the possibility that newSmbiosTable.Type1->ProductName and newSmbiosTable.Type1->SKUNumber could refer to the same index. Since those two strings are set from different sources (gSettings.ProductName and gSettings.BoardNumber, respectively), in the case the originals refer to the same index, a new string would need to be added for one of them. Right now, the BoardNumber will overwrite the ProductName (as it happens second) when they share a string index. A possible fix would be make a pass over the Smbios strings to make sure each field uses a separate string index (by adding a string with the same content, and fixing up the index at the main struct) before any of the normal patching is done. @zhhbc has done good work to find the cause of this problem... Link to comment Share on other sites More sharing options...
Recommended Posts