Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

RehabMan
RehabMan
Posted
Posted

Why? There is no syntax error.

Look carefully at the diffs. You commented out the call to UpdateSmbiosString in UniquifySmbiosTableStr. As a result, the function is ineffective.

 

Also, is this (unrelated) change to ati.c intentional?

-    { 0x689E,	0x00000000, CHIP_FAMILY_CYPRESS,	"ATI Radeon HD 5830 Series",	kUakari	},
+    { 0x689E,	0x00000000, CHIP_FAMILY_CYPRESS,	"ATI Radeon HD 5830eFInject Series",	kUakari	},
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Look carefully at the diffs. You commented out the call to UpdateSmbiosString in UniquifySmbiosTableStr. As a result, the function is ineffective.

The main purpose of the function is exclude dupes

SmbiosTableN.Raw[cmp_idx] = 0;

When there is zero then next UpdateSmbiosString will create new string and it will happen few lines below. It is OK for my look.

 

Also, is this (unrelated) change to ati.c intentional?

-    { 0x689E,	0x00000000, CHIP_FAMILY_CYPRESS,	"ATI Radeon HD 5830 Series",	kUakari	},
+    { 0x689E,	0x00000000, CHIP_FAMILY_CYPRESS,	"ATI Radeon HD 5830eFInject Series",	kUakari	},

Wah, sorry, misprint.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

The main purpose of the function is exclude dupes

SmbiosTableN.Raw[cmp_idx] = 0;
When there is zero then next UpdateSmbiosString[/size] will create new string and it will happen few lines below. It is OK for my look.

 

It only works if UpdateSmbiosString is called. It may not be called (later) for all strings that might have had dupes.

 

The idea of the function is that it is standalone, and doesn't require on later calls to UpdateSmbiosString.

 

With the code as-is, any property using a duplicate string, but not updated by the corresponding 'patch' function, will be left as undefined.

 

The call should be left in.

Link to comment
Share on other sites
zhhbc
zhhbc
Posted
Posted

@Slice,

 

@RehabMan is right. The intention of the function is uniquifying all duplicated strings regardless if they are updated later or not. For inspiron 5558, it doesn't matter as both values are updated later.  But for general case, it is safer to have it in place. Thanks,

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Guys, it is normal for OSX to have zero index in the string field. We need no all fields to be filled.

 

 

 

With the code as-is, any property using a duplicate string, but not updated by the corresponding 'patch' function, will be left as undefined.

Yes, we left them undefined. As well see reports how many strings users have undefined even not related to dupes.

 

Clover defines all strings that needed. All underfined strings and all OEM strings that Clover didn't touch not used by OSX.

If it is not as I said tell me then I improve Clover to define one more string.

 

 

Moreover Chameleon defines times less strings in smbios and it is enough for all. Just cosmetic lacks.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

All underfined strings and all OEM strings that Clover didn't touch not used by OSX.

I think it is difficult to prove your assertion above. And there is no sense in taking the risk...

 

The problem is that you're making any duplicate string undefined. If it is not updated by Clover, it will effectively be changed from what it was originally... to undefined.

 

The correct fix is the leave the UpdateSmbiosString call in.

 

The code that zhhbc provided in UniquifySmbiosTableStr does what the name of the function implies.

Your code does something else.

 

A more appropriate name for your code in UniquifySmbiosTableStr would be MakeAllDuplicateSmbiosStrIndexesUndefined.

 

If you want to instead rely on all SMBIOS strings being updated by Clover...

 

VOID MakeAllSmbiosStrIndexesUndefined(SMBIOS_STRUCTURE_POINTER SmbiosTableN, SMBIOS_TABLE_STRING* str_idx)
{
    // make all strings undefined
    while (*str_idx)
        SmbiosTableN.Raw[*str_idx++] = 0;
    // empty string table
    UINT8* strStart = SmbiosTableN.Raw + SmbiosTableN.Hdr->Length;
    strStart[0] = 0;
    strStart[1] = 0;
}
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Can you provide an example when it will not work?

You would have to find a scenario where OS X reads an SMBIOS string that is:

1) not updated/patched by Clover

2) is a duplicate of some earlier string in an SMBIOS structure (as defined in the OEM SMBIOS)

 

Not sure if that will actually happen (the two conditions are very hard to prove that they won't happen).

 

I would go with the safer fix.

 

If you want to make the 'unsafe' fix... go with MakeAllSmbiosStrIndexesUndefined instead of UniquifySmbiosTableStr. It will show a potential problem sooner.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Did you see sources of AppleSMBIOS? There are good informations what used.

I see no reason to keep OEM informations in tables 0-4.


Moreover, ElCapitan seems don't see tables 3,4.  But new table 133. OemPlatformFeature and created new property "platform-feature".


  +-o /  <class IOPlatformExpertDevice, id 0x100000112, registered, matched, active, busy 0 (3683 ms), retain 40>
    | {
    |   "compatible" = <"iMac15,1">
    |   "version" = <"1.0">
    |   "board-id" = <"Mac-42FD25EABCABB274">
    |   "IOInterruptSpecifiers" = (<0900000005000000>)
    |   "platform-feature" = <0100000000000000>

:huh:


iMac16,1 

    |   "platform-feature" =

iMac17,1 

    |   "platform-feature" =
  • Like 2
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I see no reason to keep OEM informations in tables 0-4.

Then use the code proposed in #285. It is simpler and does exactly what you propose above.

 

But note that in post #268, you wrote:

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

 

The original Uniquify solution is less risky than the current fix as checked in (and, furthermore, safer than what I propose). It is safer as it only fixes the problem as already identified, and does not affect SMBIOS without the problem.

 

That said, it may be interesting for zhhbc to try my solution proposed in #285. Analysis of the resulting SMBIOS is a bit easier, due to normalization of the SMBIOS string indexes.

Link to comment
Share on other sites
LockDown
LockDown
Posted
Posted (edited)

Is it a Grub? I was referring to a 32bit of this https://github.com/JrCs/CloverGrowerPro/tree/master/Files/NTFS/x64

 

Thank You!  :)

 

one more thing...

is clover down? Rev18686

bash-3.2# sudo ./ebuild.sh clean
TOOLCHAIN_DIR: /Users/Ella/CloverGrowerPro/edk2/Clover/../../opt/local
No clover toolchain found !
Build it with the buidgcc.sh script or defined the TOOLCHAIN_DIR variable.

UPDATE: i had to use the latest edk2 revision20311 to fix it

Edited by ellaosx
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

ebuild.sh script changed recently because I need to compile Clover from second partition without moving sources to it.

But I am not care about CloverGrowerPro, never used it. It seems new script conflict with CGP. Take older one.

 

 

PS. Just for curiosity. If you account yourself as a developer that able to compile own Clover then you should able to resolve such issue.

Else use official binaries, they works. 

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

There is a problem in ElCapitan with XCode 7 and SDK10.11.

buildgettext.sh is not working

buildnasm.sh is not working

make utilities is not working

can't compile fdisk440.

I can compile CloverX64.efi and boot files but not package.

To make Clover Package I have to return to Mavericks.

 

It was a job of JrCs and I am not sure if I can resolve these issues soon.

Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted

I dont have error for gettext and nasm 

 

My error is 

 

build.py...

 : error F000: Not supported macro is found in make command :  -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h -DSTRING_ARRAY_NAME=BasePcdLibNullStrings -m32 -malign-double -fno-stack-protector -D EFI32 -Wno-address -Wno-unused-but-set-variable -Os -flto  -c -DMDEPKG_NDEBUG -DCLOVER_BUILD $(VBIOS_PATCH_CLOVEREFI_FLAG) $(ONLY_SATA_0_FLAG) $(BLOCKIO_FLAG) $(NOUSB_FLAG) -DAMD_SUPPORT $(SECURE_BOOT_FLAG) $(PS2MOUSE_LEGACYBOOT_FLAG) $(DEBUG_ON_SERIAL_PORT_FLAG) $(NOUDMA_FLAG)

[/users/chris/src/edk2/MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf]

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Clover is compiling fine here with latest EDK2 (with clang).

Yes, Clover by itself is compiled fine. There is a problem with Package.

It can be compiled also with Clang but boot file created by clang is not started.

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