Clover General discussion

[tluck]

I think the code in IntelGraphicsDVMTFixup is sound.

Problem is in Lilu...

I will need more time to become familiar with the Lilu code.

 

For now, I'd rather use KextsToPatch.  It is simple and reliable.

 

well I put your new framebuffer patch method into AppleALC and it worked... search/replace 7 instances - instead of the patch for assertion. 

 

Comment: 0x19160000/etc, 19MB framebuffer 9MB cursor bytes (credit RehabMan)

Name: AppleIntelSKLGraphicsFramebuffer

Find: 01030303 00002002 00005001

Replace: 01030303 00003001 00009000

[bronxteck]

while you guys are on the subject of controlling the clover build options is there a way to stop the pkg from continuously installing an OEM folder maybe an option checkbox like all the other options in clover pkg installer. 

[DTK]

Hi everyone, i want to add more options to CLover GUI. For example, I want bring some options from BIOS Setting to Clover GUI so that it becomes more convenient. So, i want to ask about Graphic Library of Clover, Dose it allow me do that. Tks!

[bronxteck]

no. not really. clover is a shim between bios and boot.efi it has no control over bios functions.

[DTK]

no. not really. clover is a shim between bios and boot.efi it has no control over bios functions.

I try change source Clover to call BIOS SETTING from Clover and CLOVER from BIOS SETTING, it worked! I think i can change  functions in Bios Setting from Clover. The problem here is Graphic Lib allow me do that or not?

[apianti]

while you guys are on the subject of controlling the clover build options is there a way to stop the pkg from continuously installing an OEM folder maybe an option checkbox like all the other options in clover pkg installer. 

 

Just remove the folder from the source folder (SRC/CloverPackage/CloverV2/EFI/CLOVER/OEM) before building the package. anything under SRC/CloverPackage/CloverV2 is added to the package.

 

 

Hi everyone, i want to add more options to CLover GUI. For example, I want bring some options from BIOS Setting to Clover GUI so that it becomes more convenient. So, i want to ask about Graphic Library of Clover, Dose it allow me do that. Tks!

 

No. No idea why you would want to put firmware settings into the clover GUI menu. These settings only affect the system starting up, which is why your computer restarts when you save values and exit the menu. Clover can also not change these settings reliably since they are just variables in the firmware binaries. You may not even be able to access this because it may be in unmapped ROM (since the firmware can start then unmap regions).

 

 

I try change source Clover to call BIOS SETTING from Clover and CLOVER from BIOS SETTING, it worked! I think i can change  functions in Bios Setting from Clover. The problem here is Graphic Lib allow me do that or not?

 

What? What worked? That's nonsense. I think you may want to do something that you are confused as to what.....

[mhaeuser]

No. No idea why you would want to put firmware settings into the clover GUI menu. These settings only affect the system starting up, which is why your computer restarts when you save values and exit the menu. Clover can also not change these settings reliably since they are just variables in the firmware binaries. You may not even be able to access this because it may be in unmapped ROM (since the firmware can start then unmap regions).

All I saw use RT variables... Which obviously are not getting unmapped. Agree on the idea being pointless.

 

What? What worked? That's nonsense. I think you may want to do something that you are confused as to what.....

He probably had Clover start the FW Setup? Win 10 and Oz can do that too.

[bronxteck]

well if it's an option to enter fw setup from clover then that could make more sense to do then having exit clover option.

[apianti]

DF, you know that not all settings are in RT vars. That's just crazy. Even still, it's not like there is a standardized RT vars implementation, so if every variable was indeed stored in RT vars there's still no way of determining which variable would pertain to what setting unless you were about to do an insane database relating the name, storage type/size, and possible values to a specific setting. Also, I don't see why you can't press a key a second before entering clover as opposed to when in clover if his intention was indeed to enter the firmware menu, which I don't think it was.

well if it's an option to enter fw setup from clover then that could make more sense to do then having exit clover option.

 

That's just setting the RT var OsIndications=1 and restarting. Exiting serves an entirely different purpose and the firmware determines the action taken after, whether it's returning to the firmware boot menu or continuing on to the next boot option.

[Slice]

I will add that FW can change a device state and it can be WriteOnce (for example 0xE2 MSR) so it is too late to change BIOS setting when we are in Clover.

[mhaeuser]

DF, you know that not all settings are in RT vars. That's just crazy. Even still, it's not like there is a standardized RT vars implementation

1) As I said, I never saw anything else... I never saw.

2) He didn't sound like wanting to contribute it, but rather to have it for himself, for whatever crazy reasons he might have,

[apianti]

lol why waste time doing something that benefits practically no one then?

 

EDIT: I'm referring to myself, obviously he can go off on whatever magical quest he pleases, but he's going to be on his own if it has no interest for others.

[ctxdl]

Hey sorry for the question i cannot run clover efi on osx 10.12.4 it says its not compatible is there a workaround?

[LockDown]

Hi all

A question about the use of "-D USE_APPLE_HFSPLUS_DRIVER" and HFSPlus.efi in Legacy Mode

 

If i compile clover with "-D USE_APPLE_HFSPLUS_DRIVER", do i still need to put HFSPlus.efi in /EFI/CLOVER/drivers64/ folder or No?

 

Whatever the answer will be, will it be the same for UEFI Mode?

[Slice]

Hi all

A question about the use of "-D USE_APPLE_HFSPLUS_DRIVER" and HFSPlus.efi in Legacy Mode

 

If i compile clover with "-D USE_APPLE_HFSPLUS_DRIVER", do i still need to put HFSPlus.efi in /EFI/CLOVER/drivers64/ folder or No?

 

Whatever the answer will be, will it be the same for UEFI Mode?

Sure there are two stories.

1. Legacy mode. First started boot file (CloverEFI), second started CloverX64.efi and then drivers from /EFI/CLOVER/drivers64/ folder.

If you compiled Clover with "-D USE_APPLE_HFSPLUS_DRIVER", then the driver will be included into boot file. No need to place it in folder.

 

2. UEFI mode. First started UEFI BIOS, second started CloverX64.efi. This mode is not using boot file so you must place HFSplus.efi into /EFI/CLOVER/drivers64UEFI/ folder.

[apianti]

Hi all

A question about the use of "-D USE_APPLE_HFSPLUS_DRIVER" and HFSPlus.efi in Legacy Mode

 

If i compile clover with "-D USE_APPLE_HFSPLUS_DRIVER", do i still need to put HFSPlus.efi in /EFI/CLOVER/drivers64/ folder or No?

 

Whatever the answer will be, will it be the same for UEFI Mode?

 

If you build the legacy firmware then the driver will be inserted into the firmware instead of the vboxhfs driver, you do not need to put the driver in EFI/CLOVER/drivers64. You do need to put the driver in EFI/CLOVER/drivers64UEFI for UEFI boot no matter what (unless you modified your mobo firmware by inserting the driver).

 

EDIT: Slice beat me.

[Slice]

[tluck]

I think the code in IntelGraphicsDVMTFixup is sound.

Problem is in Lilu...

I will need more time to become familiar with the Lilu code.

 

For now, I'd rather use KextsToPatch.  It is simple and reliable.

@RehabMan - i really agree the frame buffer patch method is better than patch the assertion.

Bravo to you for cracking the code for us lap-toppers with immutable bios!!!

 

@sherlocks

- i figured out why the DVMTFixup 1.1.3 was not working.

- not a problem with Lilu

- need change your patch count for each pattern

 

Unlike, the old method which is a patch to avoid assertion, RehabMan's new buffer patches have more that 1 occurrence.

 

so here is an example :

 

changed number 1 to 7 matches for 01030303 00002002 00005001

 

                    const uint8_t find2[]    = {0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x20, 0x02, 0x00, 0x00, 0x50, 0x01};

                    const uint8_t replace2[] = {0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x30, 0x01, 0x00, 0x00, 0x90, 0x00};

                    KextPatch kext_patch2 {

                        {&kextList, find2, replace2, sizeof(find2), 7},

                        KernelVersion::ElCapitan, KernelVersion::Sierra

                    };

                    applyPatches(patcher, index, &kext_patch2, 1);

                    progressState |= ProcessingState::GraphicsFramebufferPatched;

                    DBGLOG("igdvmt @ Skylake - 01030303 00002002 00005001 :: minStolenSize patch with 32mb DVMT-prealloc was applied");

[Sherlocks]

@sherlocks

- i figured out why the DVMTFixup 1.1.3 was not working.

- not a problem with Lilu

- need change your patch count for each pattern

 

Unlike, the old method which is a patch to avoid assertion, RehabMan's new buffer patches have more that 1 occurrence.

 

so here is an example :

 

changed number 1 to 7 matches for 01030303 00002002 00005001

 

const uint8_t find2[] = {0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x20, 0x02, 0x00, 0x00, 0x50, 0x01};

const uint8_t replace2[] = {0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x30, 0x01, 0x00, 0x00, 0x90, 0x00};

KextPatch kext_patch2 {

{&kextList, find2, replace2, sizeof(find2), 7},

KernelVersion::ElCapitan, KernelVersion::Sierra

};

applyPatches(patcher, index, &kext_patch2, 1);

progressState |= ProcessingState::GraphicsFramebufferPatched;

DBGLOG("igdvmt @ Skylake - 01030303 00002002 00005001 :: minStolenSize patch with 32mb DVMT-prealloc was applied");

Can you upload file changed to fix?

I cant notice something. I will commit your code.

 

Thanks in advance

 

Added. I got it. Thank you

 

Added. Applypatch also 1 to 7? No need?

 

나의 LG-F410S 의 Tapatalk에서 보냄

[RehabMan]

@RehabMan - i really agree the frame buffer patch method is better than patch the assertion.

Bravo to you for cracking the code for us lap-toppers with immutable bios!!!

 

@sherlocks

- i figured out why the DVMTFixup 1.1.3 was not working.

- not a problem with Lilu

- need change your patch count for each pattern

 

Unlike, the old method which is a patch to avoid assertion, RehabMan's new buffer patches have more that 1 occurrence.

 

so here is an example :

 

changed number 1 to 7 matches for 01030303 00002002 00005001

 

                    const uint8_t find2[]    = {0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x20, 0x02, 0x00, 0x00, 0x50, 0x01};

                    const uint8_t replace2[] = {0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x30, 0x01, 0x00, 0x00, 0x90, 0x00};

                    KextPatch kext_patch2 {

                        {&kextList, find2, replace2, sizeof(find2), 7},

                        KernelVersion::ElCapitan, KernelVersion::Sierra

                    };

                    applyPatches(patcher, index, &kext_patch2, 1);

                    progressState |= ProcessingState::GraphicsFramebufferPatched;

                    DBGLOG("igdvmt @ Skylake - 01030303 00002002 00005001 :: minStolenSize patch with 32mb DVMT-prealloc was applied");

 

Awesome... I didn't realize what that parameter was for... at first glance, thought it had something to do with the pointer in first param.

It kind of sucks that you have to specify the number of matches (way to specify "all that match"?)... suppose you could just specify 4096 (or some other relatively large number?)

[Slice]

Awesome... I didn't realize what that parameter was for... at first glance, thought it had something to do with the pointer in first param.

It kind of sucks that you have to specify the number of matches (way to specify "all that match"?)... suppose you could just specify 4096 (or some other relatively large number?)

There looks like a bug in Clover.

We have kernel patch count

        Dict = GetProperty (Prop2, "Count");
        if (Dict != NULL) {
          Patches->KernelPatches[Patches->NrKernels].Count = GetPropertyInteger (Dict, 0);
        }

But we forgot to do this for kexts.

[apianti]

I find that count shouldn't even be an issue here, why are we not just searching the whole kernel or kext and replacing all instances. If you don't want a patch to happen in multiple places then the patch search should be made longer so it's unique.... I doubt very much that restricting the count is going to effect a great amount of compute time, or even just use zero (or lack of setting) to represent all instances. Then both ways can be used.

[vector sigma]

There looks like a bug in Clover.

We have kernel patch count

        Dict = GetProperty (Prop2, "Count");
        if (Dict != NULL) {
          Patches->KernelPatches[Patches->NrKernels].Count = GetPropertyInteger (Dict, 0);
        }

But we forgot to do this for kexts.

I see a function "UINTN SearchAndCount(UINT8 *Source, UINT32 SourceSize, UINT8 *Search, UINTN SearchSize)", so can be restricted. 

 

And in that one "UINTN SearchAndReplace(UINT8 *Source, UINT32 SourceSize, UINT8 *Search, UINTN SearchSize, UINT8 *Replace, INTN MaxReplaces)" passing <=0 there are no restriction.

You talk about these ones? Should be nice also have a start and a end location then:

 

Dict = GetProperty (Prop2, "Start")

Dict = GetProperty (Prop2, "End")

[apianti]

Yeah, was just more generally making a point about why count is not an issue. But the start and end, is impossible (or just extraneous), the binary images will be loaded at different addresses every time. I'm not sure that count is used anywhere other than for patches that are known to only be one instance, or the kernel patch count. All kext patches are passed with -1 as count.

[vector sigma]

Yeah, was just more generally making a point about why count is not an issue. 

agreed on this

But the start and end, is impossible (or just extraneous)

 

I think I said something stupid. Should be nice restrict it to segments of the mach-o binary, that was what unconsciously had in mind

the binary images will be loaded at different addresses every time.

 

Sure, but once you have "UINT8 *Source, UINT32 SourceSize" you know where is it, isn't?

meant a relative start/end. As I said stupid w/o know where to patch something, unless is a sure thing (very difficult)