Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

zhhbc
zhhbc
Posted
Posted

@Slice,

 

Here is my patch. I only did for type1, but it can be easily adopt for other types. Do you consider applying it to repository?

--- rEFIt_UEFI/Platform/smbios.c    (revision 3358)
+++ rEFIt_UEFI/Platform/smbios.c    (working copy)
@@ -84,6 +84,8 @@
 #define SMBIOS_PTR        SIGNATURE_32('_','S','M','_')
 #define MAX_TABLE_SIZE    512
 
+SMBIOS_TABLE_STRING    SMBIOS_TABLE_TYPE1_STR_IDX[] = {
+  0x04, 0x05, 0x06, 0x07, 0x19, 0x1a, 0x00};    // offsets of structures that values are strings for type 1
 
 /* Functions */
 
@@ -393,6 +395,28 @@
     return;
 }
 
+VOID UniquifySmbiosTableStr (SMBIOS_STRUCTURE_POINTER SmbiosTableN, SMBIOS_TABLE_STRING* str_idx)
+{
+    int            i, j;
+    SMBIOS_TABLE_STRING    cmp_idx;
+    SMBIOS_TABLE_STRING    cmp_str;
+    SMBIOS_TABLE_STRING    ref_str;
+    
+    if ( 0 == str_idx[0] ) return;    // SMBIOS doesn't have string structures, just return;
+    for (i = 1; ;i++) {
+        cmp_idx = str_idx[i];
+        if ( 0 == cmp_idx ) break;
+        cmp_str = SmbiosTableN.Raw[cmp_idx];
+        if ( 0 == cmp_str ) continue;        // if string is undefine, continue
+        for ( j = 0; j < i; j++ ) {
+            ref_str = SmbiosTableN.Raw[str_idx[j]];
+            if ( cmp_str == ref_str ) {
+                SmbiosTableN.Raw[cmp_idx] = 0;    // pretend the string doesn't exist
+                UpdateSmbiosString (SmbiosTableN, &SmbiosTableN.Raw[cmp_idx], GetSmbiosString(SmbiosTableN, ref_str));
+            }
+        }    
+    }
+}
 
 VOID PatchTableType1()
 {
@@ -412,6 +436,8 @@
     CopyMem((CHAR8*)newSmbiosTable.Type1+NewSize, (CHAR8*)SmbiosTable.Type1+Size, TableSize - Size); //copy strings
     newSmbiosTable.Type1->Hdr.Length = (UINT8)NewSize;
     
+    UniquifySmbiosTableStr(newSmbiosTable, SMBIOS_TABLE_TYPE1_STR_IDX);
+    
     newSmbiosTable.Type1->WakeUpType = SystemWakeupTypePowerSwitch;
     Once = TRUE;
 

@RehabMan, Thanks for confirming the issue have been observed before.

 

I am still tracking down 13 characters limitation. Maybe other block/kext touched  smbios. I will report back my finding.

Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted

I dumped smbios (with the patch in previous post) just before clover booting into osx, and the dump files looks okay. So the 13 characters limitation is not caused by clover.

 

So maybe one of extra kexts modified the SMBIOS. Here is my extra kext list:

3:206 0:000 Preparing kexts injection for arch=x86_64 from \EFI\CLOVER\kexts\Other
3:206 0:000 Extra kext: \EFI\CLOVER\kexts\Other\FakePCIID.kext
3:207 0:000 Extra kext: \EFI\CLOVER\kexts\Other\FakePCIID_Intel_HD_Graphics.kext
3:210 0:003 Extra kext: \EFI\CLOVER\kexts\Other\FakeSMC.kext
3:212 0:002 Extra kext: \EFI\CLOVER\kexts\Other\VoodooPS2Controller.kext
3:216 0:003 Extra PlugIn kext: \EFI\CLOVER\kexts\Other\VoodooPS2Controller.kext\Contents\PlugIns\VoodooPS2Keyboard.kext
3:218 0:001 Extra PlugIn kext: \EFI\CLOVER\kexts\Other\VoodooPS2Controller.kext\Contents\PlugIns\VoodooPS2Mouse.kext
3:219 0:001 Extra PlugIn kext: \EFI\CLOVER\kexts\Other\VoodooPS2Controller.kext\Contents\PlugIns\VoodooPS2Trackpad.kext
3:221 0:001 Extra kext: \EFI\CLOVER\kexts\Other\RealtekRTL8100.kext
3:230 0:008 Extra kext: \EFI\CLOVER\kexts\Other\BrcmFirmwareData.kext
3:239 0:009 Extra kext: \EFI\CLOVER\kexts\Other\ACPIBacklight.kext
3:241 0:001 Extra kext: \EFI\CLOVER\kexts\Other\BrcmPatchRAM2.kext
3:246 0:005 Extra kext: \EFI\CLOVER\kexts\Other\ACPIBatteryManager.kext
3:248 0:001 Preparing kexts injection for arch=x86_64 from \EFI\CLOVER\kexts\10.11

I think FakeSMC.kext may be the cause. I didn't remember where I grabbed fakesmc, where is latest official FakeSMC?

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I dumped smbios (with the patch in previous post) just before clover booting into osx, and the dump files looks okay. So the 13 characters limitation is not caused by clover.

Perhaps you should provide your raw SMBIOS table1 and SMBIOS section of config.plist.

 

Are you sure you're using a correct board-id? For MacBookPro11,1, you should have more characters than 'MAC-189A3D4F9'...

 

Note: There are many "latest" FakeSMC.kext.

Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted
Are you sure you're using a correct board-id? For MacBookPro11,1, you should have more characters than 'MAC-189A3D4F9'...

 

Yes, I used correct board-id (Mac-189A3D4F975D5FFC). However, in smbios it becomes "Mac-189A3D4F9       ", the 7 characters after 13th become spaces(0x20), (that is the same problem that "MacBookPro11,1" becomes "MacBookPro11"), the productname from "ioreg -l" is "Mac-189A3D4F9" with trailing white space removed by AppleSMBIOS kext ( I think).

 

 

Note: There are many "latest" FakeSMC.kext.

Could you please recommend one for me to try?

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Yes, I used correct board-id (Mac-189A3D4F975D5FFC). However, in smbios it becomes "Mac-189A3D4F9       ", the 7 characters after 13th become spaces(0x20), (that is the same problem that "MacBookPro11,1" becomes "MacBookPro11"), the productname from "ioreg -l" is "Mac-189A3D4F9" with trailing white space removed by AppleSMBIOS kext ( I think).

You might check the SMBIOS patching code to see that is creating SMBIOS bits that make sense...

 

If I was you, I'd pull the code out of Clover and put into standalone program to test independently with your SMBIOS test case...

 

 

Could you please recommend one for me to try?

I use my own forked from kozleks... I don't think FakeSMC has anything to do with your issue...

Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted

You might check the SMBIOS patching code to see that is creating SMBIOS bits that make sense...

 

If I was you, I'd pull the code out of Clover and put into standalone program to test independently with your SMBIOS test case...

I already checked SMBIOS codes, and dumped smbios after patch has been done, the 13 byte truncation problem was not here. At this point, I dont think clover causes truncation problem.

 

I use my own forked from kozleks... I don't think FakeSMC has anything to do with your issue...

 

Thanks, I will try kozleks' version. FakeSMC does process SMBIOS, I need study the source code more though.

https://github.com/kozlek/HWSensors/blob/2c7d7818c6bbaf3777cddd141158c515201d71fc/Shared/OEMInfo.cpp

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I already checked SMBIOS codes, and dumped smbios after patch has been done, the 13 byte truncation problem was not here. At this point, I dont think clover causes truncation problem.

You should publish your results here.

 

Thanks, I will try kozleks' version. FakeSMC does process SMBIOS, I need study the source code more though.

https://github.com/kozlek/HWSensors/blob/2c7d7818c6bbaf3777cddd141158c515201d71fc/Shared/OEMInfo.cpp

Yes, it does, but it only does that in order to do profile/configuration lookup (eg. read only).

Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted

You should publish your results here.

Not sure about your comments. I already posted my patch to fix "share" string index problem. As to 13 character limitation, it doesn't seem to be clover issue.

 

Yes, it does, but it only does that in order to do profile/configuration lookup (eg. read only).

 

You are right. Now I have no clue which program/kext impose the 13 character limitation. the limitation is for ProductName and SKUNumber, other fields in type1 don't suffer this.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Not sure about your comments. I already posted my patch to fix "share" string index problem.

No data provided. Without your OEM SMBIOS data, not possible to test/verify with the Clover code.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

@Slice,

 

Here is my patch. I only did for type1, but it can be easily adopt for other types. Do you consider applying it to repository?

--- rEFIt_UEFI/Platform/smbios.c    (revision 3358)
+++ rEFIt_UEFI/Platform/smbios.c    (working copy)
@@ -84,6 +84,8 @@
 #define SMBIOS_PTR        SIGNATURE_32('_','S','M','_')
 #define MAX_TABLE_SIZE    512
 
+SMBIOS_TABLE_STRING    SMBIOS_TABLE_TYPE1_STR_IDX[] = {
+  0x04, 0x05, 0x06, 0x07, 0x19, 0x1a, 0x00};    // offsets of structures that values are strings for type 1
 
 /* Functions */
 
@@ -393,6 +395,28 @@
     return;
 }
 
+VOID UniquifySmbiosTableStr (SMBIOS_STRUCTURE_POINTER SmbiosTableN, SMBIOS_TABLE_STRING* str_idx)
+{
+    int            i, j;
+    SMBIOS_TABLE_STRING    cmp_idx;
+    SMBIOS_TABLE_STRING    cmp_str;
+    SMBIOS_TABLE_STRING    ref_str;
+    
+    if ( 0 == str_idx[0] ) return;    // SMBIOS doesn't have string structures, just return;
+    for (i = 1; ;i++) {
+        cmp_idx = str_idx[i];
+        if ( 0 == cmp_idx ) break;
+        cmp_str = SmbiosTableN.Raw[cmp_idx];
+        if ( 0 == cmp_str ) continue;        // if string is undefine, continue
+        for ( j = 0; j < i; j++ ) {
+            ref_str = SmbiosTableN.Raw[str_idx[j]];
+            if ( cmp_str == ref_str ) {
+                SmbiosTableN.Raw[cmp_idx] = 0;    // pretend the string doesn't exist
+                UpdateSmbiosString (SmbiosTableN, &SmbiosTableN.Raw[cmp_idx], GetSmbiosString(SmbiosTableN, ref_str));
+            }
+        }    
+    }
+}
 
 VOID PatchTableType1()
 {
@@ -412,6 +436,8 @@
     CopyMem((CHAR8*)newSmbiosTable.Type1+NewSize, (CHAR8*)SmbiosTable.Type1+Size, TableSize - Size); //copy strings
     newSmbiosTable.Type1->Hdr.Length = (UINT8)NewSize;
     
+    UniquifySmbiosTableStr(newSmbiosTable, SMBIOS_TABLE_TYPE1_STR_IDX);
+    
     newSmbiosTable.Type1->WakeUpType = SystemWakeupTypePowerSwitch;
     Once = TRUE;
 

No. This is not an array

+        cmp_str = SmbiosTableN.Raw[cmp_idx];
Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted

It is a pointer (to a union of structs). You should probably study the code a bit more...

 

from SmbiosA.h

typedef union {
  SMBIOS_TABLE_HEADER   *Hdr;
  SMBIOS_TABLE_TYPE0    *Type0;
  SMBIOS_TABLE_TYPE1    *Type1;
...
  UINT8                 *Raw;
} SMBIOS_STRUCTURE_POINTER;

SmbiosTableN is union of pointers to structs, so SmbiosTableN.raw is pointer to array of UINT8. did I miss anything?

 

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

from SmbiosA.h

typedef union {
  SMBIOS_TABLE_HEADER   *Hdr;
  SMBIOS_TABLE_TYPE0    *Type0;
  SMBIOS_TABLE_TYPE1    *Type1;
...
  UINT8                 *Raw;
} SMBIOS_STRUCTURE_POINTER;
SmbiosTableN is union of pointers to structs, so SmbiosTableN.raw is pointer to array of UINT8. did I miss anything?

 

.Raw should get you UINT8*. Maybe Slice overlooked that you were looking at SmbiosTableN.Raw and not SmbiosTableN.

 

I still think it would be helpful if you would post your data. Then a proper test case (outside of Clover) can be created. I'm not really certain whether your code rebuilds the SMBIOS string table correctly. It looks like it is creating orphans (strings not referenced) in the table...

 

Note: Using offsetof for your table (instead of hardcoded assumed byte offsets) might help clarify how it being used...

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

.Raw should get you UINT8*. Maybe Slice overlooked that you were looking at SmbiosTableN.Raw and not SmbiosTableN.

 

I still think it would be helpful if you would post your data. Then a proper test case (outside of Clover) can be created. I'm not really certain whether your code rebuilds the SMBIOS string table correctly. It looks like it is creating orphans (strings not referenced) in the table...

 

Note: Using offsetof for your table (instead of hardcoded assumed byte offsets) might help clarify how it being used...

Yes, I meant it is wrong programming style to access a structure element as an array element while C-coders often do this.

I also afraid to change anything in smbios.c because it works fine.

There is a limitation in strings length as 64bytes if it does matter. And we need no safe a space by reusing strings. Let they to be twice.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I also afraid to change anything in smbios.c because it works fine.

This code is definitely bugged as I mentioned in post #253.

 

Where two different properties use the same string index (because the strings are the same in the original OEM table), the code definitely does the wrong thing.

 

The "Uniquify" code should probably construct an entirely new SMBIOS data that contains each of the original strings duplicated (with their own index).

 

There is a limitation in strings length as 64bytes if it does matter. And we need no safe a space by reusing strings. Let they to be twice.

The problem is not that the code in smbios.c is reusing strings. It is that the OEM originally "saved space" by reusing strings... And that confuses the code in smbios.c.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

OK, I understand...


@zhhbc

Make, please, dump of your native SMBIOS to see what and where.

It is possible:

1. From Windows, AIDA64 report.

2. From Clover GUI, call Shell64.efi, type command

shell>smbios > smbios.txt


or viewsmbios, I didn't remember exactly.

There is a help command.

Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted

@Slice @RehabMan

 

Here is type1 dump from shell64.efi:

Type=1, Handle=0x1
Dump Structure as:
Index=7,Length=0x3F,Addr=0xEDDC2
00000000: 01 1B 01 00 01 03 02 04-44 45 4C 4C 4B 00 10 46  *........DELLK..F*
00000010: 80 4D B9 C7 4F 36 38 35-06 03 00 44 65 6C 6C 20  *.M..O685...Dell *
00000020: 49 6E 63 2E 00 30 31 00-49 6E 73 70 69 72 6F 6E  *Inc..01.Inspiron*
00000030: 20 35 35 35 38 00 39 4B-46 4D 36 38 35 00 00     * 5558.9KFM685..*
Structure Type: System Information
Format part Len : 27
Structure Handle: 1
Manufacturer: Dell Inc.
ProductName: Inspiron 5558
Version: 01
SerialNumber: 9KFM685
Dump Uuid
size=16:
00000000: 44 45 4C 4C 4B 00 10 46-80 4D B9 C7 4F 36 38 35  *DELLK..F.M..O685*
System Wakeup Type: Power Switch
SKUNumber: Inspiron 5558
Family:

@RehabMan,

 

I see your point. But standard offsetof macro does not work due to "-Werror=pointer-to-int-cast" option used in Makefile.

src/edk2/Clover/Library/OpensslLib/Include/OpenSslSupport.h:75:34: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
 #define offsetof(type, member) ( (int) & ((type*)0) -> member )
                                  ^
src/edk2/Clover/rEFIt_UEFI/Platform/smbios.c:91:2: note: in expansion of macro 'offsetof'
  offsetof(SMBIOS_TABLE_TYPE1, Manufacturer),
  ^
cc1: all warnings being treated as errors
make: *** [src/edk2/Build/Clover/RELEASE_GCC49/X64/Clover/rEFIt_UEFI/refit/OUTPUT/Platform/smbios.obj] Error 1

I had to create my own version, the new patch is :

--- rEFIt_UEFI/Platform/smbios.c    (revision 3358)
+++ rEFIt_UEFI/Platform/smbios.c    (working copy)
@@ -84,7 +84,17 @@
 #define SMBIOS_PTR        SIGNATURE_32('_','S','M','_')
 #define MAX_TABLE_SIZE    512
 
+#define smbios_offsetof(s,m) ( (SMBIOS_TABLE_STRING) ((char *)&((s*)0)->m - (char*)0))
 
+SMBIOS_TABLE_STRING    SMBIOS_TABLE_TYPE1_STR_IDX[] = {
+    smbios_offsetof(SMBIOS_TABLE_TYPE1, Manufacturer),
+    smbios_offsetof(SMBIOS_TABLE_TYPE1, ProductName),
+    smbios_offsetof(SMBIOS_TABLE_TYPE1, Version),
+    smbios_offsetof(SMBIOS_TABLE_TYPE1, SerialNumber),
+    smbios_offsetof(SMBIOS_TABLE_TYPE1, SKUNumber),
+    smbios_offsetof(SMBIOS_TABLE_TYPE1, Family),
+    0x00 }; // offsets of structures that values are strings for type 1
+
 /* Functions */
 
 // validate the SMBIOS entry point structure
@@ -393,6 +403,28 @@
     return;
 }
 
+VOID UniquifySmbiosTableStr (SMBIOS_STRUCTURE_POINTER SmbiosTableN, SMBIOS_TABLE_STRING* str_idx)
+{
+    int            i, j;
+    SMBIOS_TABLE_STRING    cmp_idx;
+    SMBIOS_TABLE_STRING    cmp_str;
+    SMBIOS_TABLE_STRING    ref_str;
+    
+    if ( 0 == str_idx[0] ) return;    // SMBIOS doesn't have string structures, just return;
+    for (i = 1; ;i++) {
+        cmp_idx = str_idx[i];
+        if ( 0 == cmp_idx ) break;
+        cmp_str = SmbiosTableN.Raw[cmp_idx];
+        if ( 0 == cmp_str ) continue;        // if string is undefine, continue
+        for ( j = 0; j < i; j++ ) {
+            ref_str = SmbiosTableN.Raw[str_idx[j]];
+            if ( cmp_str == ref_str ) {
+                SmbiosTableN.Raw[cmp_idx] = 0;    // pretend the string doesn't exist
+                UpdateSmbiosString (SmbiosTableN, &SmbiosTableN.Raw[cmp_idx], GetSmbiosString(SmbiosTableN, ref_str));
+            }
+        }    
+    }
+}
 
 VOID PatchTableType1()
 {
@@ -412,6 +444,8 @@
     CopyMem((CHAR8*)newSmbiosTable.Type1+NewSize, (CHAR8*)SmbiosTable.Type1+Size, TableSize - Size); //copy strings
     newSmbiosTable.Type1->Hdr.Length = (UINT8)NewSize;
     
+    UniquifySmbiosTableStr(newSmbiosTable, SMBIOS_TABLE_TYPE1_STR_IDX);
+    
     newSmbiosTable.Type1->WakeUpType = SystemWakeupTypePowerSwitch;
     Once = TRUE;
     

 

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

OK, good. I will accept your patch.

I had to do this manually, don't know why

File to patch: rEFIt_UEFI/Platform/smbios.c
patching file rEFIt_UEFI/Platform/smbios.c
Hunk #1 FAILED at 84.
Hunk #2 FAILED at 403.
Hunk #3 FAILED at 444.
3 out of 3 hunks FAILED -- saving rejects to file rEFIt_UEFI/Platform/smbios.c.rej

Committed to 3359.

How do you think, should we do the same for other tables?

  • Like 1
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I'm not really certain whether your code rebuilds the SMBIOS string table correctly. It looks like it is creating orphans (strings not referenced) in the table...

@zhhbc,

 

After further study (and creating a unit test), I can see why orphans are not created (only shared indexes are added to the end of the string table).

 

Note that you could 'break' from the j loop after UpdateSmbiosString:

        for ( j = 0; j < i; j++ ) {
            ref_str = SmbiosTableN.Raw[str_idx[j]];
            if ( cmp_str == ref_str ) {
                SmbiosTableN.Raw[cmp_idx] = 0;    // pretend the string doesn't exist
                UpdateSmbiosString (SmbiosTableN, &SmbiosTableN.Raw[cmp_idx], GetSmbiosString(SmbiosTableN, ref_str));
                break;
...
Because once you find the shared index and create the new string, you won't find any others (they have already been found and made unique, and you would not want to create two strings for this 'i' anyway...)

As to 13 character limitation, it doesn't seem to be clover issue.

Note that there are several FakeSMC keys that are imported from Clover. The value of these keys depend on the SMBIOS in use. Current Clover code does not support some of the new SMBIOS and therefore does not provide the correct keys for FakeSMC...

 

see platformdata.c for more info..

 

Not sure if that problem is actually related to your 13 character issue or not...

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

@zhhbc,

 

After further study (and creating a unit test), I can see why orphans are not created (only shared indexes are added to the end of the string table).

 

Note that you could 'break' from the j loop after UpdateSmbiosString:

        for ( j = 0; j < i; j++ ) {
            ref_str = SmbiosTableN.Raw[str_idx[j]];
            if ( cmp_str == ref_str ) {
                SmbiosTableN.Raw[cmp_idx] = 0;    // pretend the string doesn't exist
                UpdateSmbiosString (SmbiosTableN, &SmbiosTableN.Raw[cmp_idx], GetSmbiosString(SmbiosTableN, ref_str));
                break;
...
Because once you find the shared index and create the new string, you won't find any others (they have already been found and made unique, and you would not want to create two strings for this 'i' anyway...)

 

Agree,  :wink_anim:

I may notice also that we don't need this UpdateSmbiosString(0 because it contains old OEM value that we want to overwrite further...

Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted

OK, good. I will accept your patch.

 

I had to do this manually, don't know why

File to patch: rEFIt_UEFI/Platform/smbios.c
patching file rEFIt_UEFI/Platform/smbios.c
Hunk #1 FAILED at 84.
Hunk #2 FAILED at 403.
Hunk #3 FAILED at 444.
3 out of 3 hunks FAILED -- saving rejects to file rEFIt_UEFI/Platform/smbios.c.rej

Committed to 3359.

How do you think, should we do the same for other tables?

Thanks for accepting patch.

 

My guess that the reason that auto patch didn't work is that "smbios.c" uses LF+CR for newline (dos format), the patch you created, may be is unix style (LF only)

 

It will be a good idea that we do the same for other tables as you suggested

@zhhbc,

 

After further study (and creating a unit test), I can see why orphans are not created (only shared indexes are added to the end of the string table).

 

Note that you could 'break' from the j loop after UpdateSmbiosString:

        for ( j = 0; j < i; j++ ) {
            ref_str = SmbiosTableN.Raw[str_idx[j]];
            if ( cmp_str == ref_str ) {
                SmbiosTableN.Raw[cmp_idx] = 0;    // pretend the string doesn't exist
                UpdateSmbiosString (SmbiosTableN, &SmbiosTableN.Raw[cmp_idx], GetSmbiosString(SmbiosTableN, ref_str));
                break;
...

Because once you find the shared index and create the new string, you won't find any others (they have already been found and made unique, and you would not want to create two strings for this 'i' anyway...)

 

 

great catch. Yes, "break" should be used here.

 

Note that there are several FakeSMC keys that are imported from Clover. The value of these keys depend on the SMBIOS in use. Current Clover code does not support some of the new SMBIOS and therefore does not provide the correct keys for FakeSMC...

 

see platformdata.c for more info..

 

Not sure if that problem is actually related to your 13 character issue or not...

 

Yes, I saw fakesmc update product-name using OEMVendor, but even with a fix, I still have the same problem. Any other suggestion where I could check for 13 character problem?

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Yes, I saw fakesmc update product-name using OEMVendor, but even with a fix, I still have the same problem. Any other suggestion where I could check for 13 character problem?

There are other keys imported by FakeSMC from Clover... But I don't think it is related as you're using MacBookPro11,x which is supported by Clover...

 

Did you check your injected SMBIOS in ioreg to see that looks as you expect?

Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted

Did you check your injected SMBIOS in ioreg to see that looks as you expect?

Yes, I did check, actually, that was the first thing I checked after saw wrong productname. Unfortunately, it was incorrect. What puzzled me is that the dump from clover before booting into osx is correct. But after booting into el capitan, the smbios is incorrect ( from ioreg), the smbios pointed by "efi/configuration-table/EB9D2D31..." is incorrect, the productname from IOService is incorrect.  They are all wrong in the same way :no: . So I think SMBIOS or /efi has been altered before AppleSMBIOS loaded.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...