Clover General discussion

[mhaeuser]

We were just revising some AptioFix stuff...

https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/OsxAptioFixDrv/Lib.c#l380

 

Are there any real technical details on this?

1) There is no source for the range... or a description of what the issue even is.

2) The kernel treats Reserved (that's what I expect it to be... or isn't it?) the same way as it treats ACPI_NVS afaik (please correct me if wrong... with sources).

3) The kernel only uses EFI_MEMORY_RUNTIME and some other, proprietary one, so setting it to 0 should have no effect, if the region there does not have RT set.

 

tyvm

[apianti]

We were just revising some AptioFix stuff...

https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/OsxAptioFixDrv/Lib.c#l380

 

Are there any real technical details on this?

1) There is no source for the range... or a description of what the issue even is.

2) The kernel treats Reserved (that's what I expect it to be... or isn't it?) the same way as it treats ACPI_NVS afaik (please correct me if wrong... with sources).

3) The kernel only uses EFI_MEMORY_RUNTIME and some other, proprietary one, so setting it to 0 should have no effect, if the region there does not have RT set.

 

tyvm

 

Because he wants to get rid of that region, he set it to a type and attribute he knew would be ignored by the kernel, it has to do with like the first generation of pure UEFI gigabyte boards. I seem to recall some stupid region being there. Not sure why we want to get rid of reserved areas before that though, probably need those and might explain why HD3000 has some issues. It may be because they need to be rwx... But there's gotta be a better solution than just disappearing it. I'm not a big fan of just disappearing memory like it's a mobster with cement shoes.....

[mhaeuser]

Because he wants to get rid of that region, he set it to a type and attribute he knew would be ignored by the kernel, it has to do with like the first generation of pure UEFI gigabyte boards. I seem to recall some stupid region being there. Not sure why we want to get rid of reserved areas before that though, probably need those and might explain why HD3000 has some issues. It may be because they need to be rwx... But there's gotta be a better solution than just disappearing it. I'm not a big fan of just disappearing memory like it's a mobster with cement shoes.....

 

Are you sure that the issue you are remembering is not the one above, by dmazar? That was discussed on POSX in 2012. That "sleep fix" is rather new

[apianti]

Are you sure that the issue you are remembering is not the one above, by dmazar? That was discussed on POSX in 2012. That "sleep fix" is rather new

 

Which one? I said two different things. The first was slice adding that because he had a gigabyte board that has that weird region and needed it removed I guess, I think the lines commented below that are also from him. The other, the reserved regions is dmazar, and I was just wondering why he disappeared a reserved region for the GPUs. I did not use different nouns for either of them so it reads weird... lol.

 

EDIT: I don't remember exactly what the conversation about it from 2012 was. But looking at it now, I think it was a mistake to not try fix the region instead of destroying it.

[mhaeuser]

Which one? I said two different things. The first was slice adding that because he had a gigabyte board that has that weird region and needed it removed I guess, I think the lines commented below that are also from him. The other, the reserved regions is dmazar, and I was just wondering why he disappeared a reserved region for the GPUs. I did not use different nouns for either of them so it reads weird... lol.

 

EDIT: I don't remember exactly what the conversation about it from 2012 was. But looking at it now, I think it was a mistake to not try fix the region instead of destroying it.

 

Nah, I just don't remember there ever being any talk about that sleep fix... in fact it was added a commit doing mostly unrelated stuff, it's not even mentioned in the log lol.

 

Anyway, if you are at your dev setup dmazar's workaround should be changed to changing the region to MMIO (which was proven to work back then too), The issue was probably boot.efi ignoring RT Reserved, so not assigning a virtual address, and the kernel then trying to map it, which of course blows up. MMIO ensures it stays in the same physical location, is not cached (we don't know what it is used for after all...) and gets a valid vAddress.

[apianti]

Nah, I just don't remember there ever being any talk about that sleep fix... in fact it was added a commit doing mostly unrelated stuff, it's not even mentioned in the log lol.

 

Oh, there was no talk of it. He just did it. I seem to recall one day he said something and then it was done. I don't think it really affects anything but it should probably be a little more precise....

 

EDIT: Maybe it could possibly even be removed now, after the newest changes.

 

Anyway, if you are at your dev setup dmazar's workaround should be changed to changing the region to MMIO (which was proven to work back then too), The issue was probably boot.efi ignoring RT Reserved, so not assigning a virtual address, and the kernel then trying to map it, which of course blows up. MMIO ensures it stays in the same physical location, is not cached (we don't know what it is used for after all...) and gets a valid vAddress.

 

Yeah, that's what I meant, I don't know why he just destroyed the region. But it could need to be rwx like I said and we both know that the kernel doesn't seem to want to allow that. His comments around the commented out stuff don't make sense though... He says that MMIO blocks during DefragmentRuntimeServices, but why would that be the case? Maybe he just switched the comments wrong. Now I want to see what actually does work since I have an HD3000. Except it currently doesn't work in clover because the injection is broken.... Grrr.

[Funky frank]

Btw. maybe offtopic, but I never was able to properly use the Intel HD4600 next to a AMD or nvidia gfx, using it as a secondary OpenCL processor: On 10.9 it caused visual graphics glitches in Maps.app, in 10.12+10.13 it works in Maps.app, but final Cut will crash.  Luxmark works.  Maybe this is related to some memory mapping problem, too?

[mhaeuser]

He says that MMIO blocks during DefragmentRuntimeServices, but why would that be the case? Maybe he just switched the comments wrong.

 

Yes, he switched them.

[apianti]

Btw. maybe offtopic, but I never was able to properly use the Intel HD4600 next to a AMD or nvidia gfx, using it as a secondary OpenCL processor: On 10.9 it caused visual graphics glitches in Maps.app, in 10.12+10.13 it works in Maps.app, but final Cut will crash.  Luxmark works.  Maybe this is related to some memory mapping problem, too?

 

Well it's hard to say, it could be, or it could have just been bugs in the driver. Or flawed injection. Or bad configuration. Or a million other things.... But I'd probably put the odds that yes, just destroying reserved regions for the graphics is probably not a good idea and causes problems....

[Funky frank]

Btw. maybe offtopic, but I never was able to properly use the Intel HD4600 next to a AMD or nvidia gfx, using it as a secondary OpenCL processor: On 10.9 it caused visual graphics glitches in Maps.app, in 10.12+10.13 it works in Maps.app, but final Cut will crash.  Luxmark works.  Maybe this is related to some memory mapping problem, too?

 

OMG, this AptioFix V1 makes HD4600 + nvidia work in final cut!

[apianti]

 

OMG, this AptioFix V1 makes HD4600 + nvidia work in final cut!

 

Please try r4369 AptioFix2.

I WANT TO DESTROY APTIOFIX1! I NEED YOU TO NOT USE IT!!! TEST APTIOFIX2!!!!!!!!!! OBEY YOUR OVERLORDS!!!!!!!! I have taken too much medicine....

OsxAptioFix2Drv-64.efi

[Funky frank]

Please try r4369 AptioFix2.

 

I WANT TO DESTROY APTIOFIX1! I NEED YOU TO NOT USE IT!!! TEST APTIOFIX2!!!!!!!!!! OBEY YOUR OVERLORDS!!!!!!!! I have taken too much medicine....

Lol. Yes, that one works nicely, too!

[apianti]

@Slice, 

 

Hey, sorry for the premature packaging... lol. But there was a problem with r4368, can you please remove that package and make r4369 newest package?

Lol. Yes, that one works nicely, too!

 

Yes this is what I want to hear. FROM EVERYONE. 

 

EDIT: Use AptioFix2 then.

[Regi Yassin]

on my system, x99, aptiofix2 would not boot without slide=128, without it, does printf work?

aptiofix 1 is ok.

[xtddd]

@Slice, 

 

Hey, sorry for the premature packaging... lol. But there was a problem with r4368, can you please remove that package and make r4369 newest package?

 

Yes this is what I want to hear. FROM EVERYONE. 

 

EDIT: Use AptioFix2 then.

i always use AptioFix2 and no problems..

[apianti]

on my system, x99, aptiofix2 would not boot without slide=128, without it, does printf work?

aptiofix 1 is ok.

 

Yes you need to enter a slide value sometimes to get AptioFix2 to work. Maybe it should be modified to determine that on it's own. I want to obsolete AptioFix.... Make AptioFix2 the one method to rule them all! Also rename it.... lol

 

EDIT: Test the newest AptioFix2 and see what the result is. Using a slide is not a big deal, it's done anyway to place the kernel.

 

i always use AptioFix2 and no problems..

 

The newest AptioFix2 from r4369 should be very different than the previous and should give you very close to 100% working system besides a few caveats that still need fixed but I want to get rid of AptioFix and rename AptioFix2 to something more appropriate. There should not be a need for AptioFix anymore as AptioFix2 should be sufficiently modified to work for every system. Or at least I hope.

Also everyone testing this driver, if you have EmuVar driver remove that because you should have working NVRAM.

[vit9696]

I want to get rid of AptioFix and rename AptioFix2 to something more appropriate. There should not be a need for AptioFix anymore as AptioFix2 should be sufficiently modified to work for every system. Or at least I hope.

 

That may be a good idea. Here I currently have a private copy of AptioFixV2, which I slightly refactored and cleaned from legacy & AptioFixV1 code.

In addition to that, as Fritz mentioned above, we slowly walked through some fixes and additions and discovered potential issues & dead code. 

I am not sure that it will be seriously changed any further (I will probably not do proper hibernation handoff), but if the cleaned code is proven to work with time I will share it.

[Funky frank]

Hm, nvidia + hd4600 works, but in recent Firefox, 1080p60 youtube videos will stop sometimes (not so using nvidia only). Unsure if it is a Firefox issue or some kind of latency / synchronisation issue?  Luxmark showed better results with both enabled (8960 vs. 7275)

[Regi Yassin]

Yes you need to enter a slide value sometimes to get AptioFix2 to work. Maybe it should be modified to determine that on it's own. I want to obsolete AptioFix.... Make AptioFix2 the one method to rule them all! Also rename it.... lol

 

EDIT: Test the newest AptioFix2 and see what the result is. Using a slide is not a big deal, it's done anyway to place the kernel.

 

where can i get the newest AptioFix2 ? im using r4369, is it the newest ?

how can i figure what slide value is proper for my system? is 128 ok ?

[apianti]

Hm, nvidia + hd4600 works, but in recent Firefox, 1080p60 youtube videos will stop sometimes (not so using nvidia only). Unsure if it is a Firefox issue or some kind of latency / synchronisation issue?  Luxmark showed better results with both enabled (8960 vs. 7275)

 

It's hard to say, I think that some code needs refactored or removed from the fix as it no longer is relevant and some decisions made years ago are no longer viable or were never viable, where we decided working was better than not.... I have a feeling that the code DF and I were just talking about plays a big part in intel GPUs problems that seem to appear. Like HD3000 artifacts/sync issues and HD4000+ HDCP issues.

where can i get the newest AptioFix2 ? im using r4369, is it the newest ?

how can i figure what slide value is proper for my system? is 128 ok ?

 

I posted it a few posts back but r4369 is newest. I also gave method for determining slide if needed a few posts ago.

 

Care to share??

 

I posted mostly the same driver a few posts ago. He meant he just cleaned it up, refactored, and removed some stuff not needed, I imagine he will release it when it's ready, like he said.

[Slice]

4369 released.

@all, please more comments about changes:

1. Sleep/Wake (mode=0)

2. Hibernation (mode=25)

3. NVRAM without EmuVariableUefi

4. Intel graphics artefacts.

[apianti]

4369 released.

@all, please more comments about changes:

1. Sleep/Wake (mode=0)

2. Hibernation (mode=25)

3. NVRAM without EmuVariableUefi

4. Intel graphics artefacts.

 

Runtime code areas are no longer allowed to be relocated by boot.efi like runtime data areas. Runtime methods for NVRAM variables are shimmed to enable writing into runtime code regions during the methods, then disabled upon return. Native NVRAM should work for everyone now. Sleep/hibernation has been a discussion, unsure, it may be broken, but fixable? That will be a longer term evaluation, but I think we all pretty much agree that it is not correct and will need fixed (there may be an element of luck for success). The Intel graphics problem, not fixed, just discussed the removing of the reserved area for these GPUs and how it's probably a better idea to somehow preserve this region because why would it exist if it wasn't needed?

 

EDIT: Forgot, thanks for the package update.

[SavageAUS]

Yes you need to enter a slide value sometimes to get AptioFix2 to work. Maybe it should be modified to determine that on it's own. I want to obsolete AptioFix.... Make AptioFix2 the one method to rule them all! Also rename it.... lol

 

EDIT: Test the newest AptioFix2 and see what the result is. Using a slide is not a big deal, it's done anyway to place the kernel.

 

 

The newest AptioFix2 from r4369 should be very different than the previous and should give you very close to 100% working system besides a few caveats that still need fixed but I want to get rid of AptioFix and rename AptioFix2 to something more appropriate. There should not be a need for AptioFix anymore as AptioFix2 should be sufficiently modified to work for every system. Or at least I hope.

Also everyone testing this driver, if you have EmuVar driver remove that because you should have working NVRAM.

Desktop hack in sig.

I previously used EmuVar (for nvidia card) but with Clover 4369 i removed EmuVar and rebooted without issue.

GTX 960 working as it should.

NVRAM appears functional.

EDIT:

Maybe not

[apianti]

Desktop hack in sig.

I previously used EmuVar (for nvidia card) but with Clover 4369 i removed EmuVar and rebooted without issue.

GTX 960 working as it should.

NVRAM appears functional.

EDIT:

Maybe not

 

To test whether it is working go into terminal and use the command like

sudo nvram test="value"

Then restart and run

sudo nvram -p

And see if the test variable is there. You can then delete it:

sudo nvram -d test

If the variable is not there you do not have working NVRAM. Would need to get more info then.

[SavageAUS]

To test whether it is working go into terminal and use the command like

sudo nvram test="value"

Then restart and run

sudo nvram -p

And see if the test variable is there. You can then delete it:

sudo nvram -d test

If the variable is not there you do not have working NVRAM. Would need to get more info then.

NVRAM is functional. I used the code you provided and after reboot in NVRAM I see

test value

Sent from my SM-G930F using Tapatalk