Jump to content

Clover General discussion


ErmaC
29,818 posts in this topic

Recommended Posts

Yes, I use OsxAptioFixDrv-64.efi + Test2-2016.efi..

 

Switched now to Clover r4369... 

 

Everything works again as expected.. Many thanks for the extremely useful hint. 

 

However, like in Clover r4366, I am not able to boot the 10.13.2 USB Flash Drive Installer with SMBIOS iMacPro1,1. 

 

Guess the problem is however not Clover.. The problem might be that the iMacPro BoardID and iMacPro1,1 ModelProperties are not part of the PlatfromSupport.plist of the macOS 10.13.2 Installer Package. 

 

They are not supported fully yet. But you should not be using those two drivers together, ever. Please remove those two drivers and use only the newest revisions AptioFix2. You may need to add a slide=N argument if it doesn't find a region to place the kernel.

  • Like 2
Link to comment
Share on other sites

They are not supported fully yet. But you should not be using those two drivers together, ever. Please remove those two drivers and use only the newest revisions AptioFix2. You may need to add a slide=N argument if it doesn't find a region to place the kernel.

 

Is there any reason why I should not use these two drivers together with Skylake-X/X299? They work absolutely flawless, while AptioFix2 still leads to occasional memory allocation errors at early boot... 

Link to comment
Share on other sites

Is there any reason why I should not use these two drivers together with Skylake-X/X299? They work absolutely flawless, while AptioFix2 still leads to occasional memory allocation errors at early boot... 

 

You should try using just AptioFix2 with r4369. It should work. The memory allocation error is another issue, it should not happen as often now as not as much will be needed without relocating runtime. That's due to firmware memory fragmentation. The reason not to use the two drivers is because first they are meant to only be used alone. Second, the one not named AptioFix just deletes random memory below a certain address with no idea what the memory is used for...

  • Like 2
Link to comment
Share on other sites

You should try using just AptioFix2 with r4639. It should work. The memory allocation error is another issue, it should not happen as often now as not as much will be needed without relocating runtime. That's due to firmware memory fragmentation. The reason not to use the two drivers is because first they are meant to only be used alone. Second, the one not named AptioFix just deletes random memory below a certain address with no idea what the memory is used for...

 

O.k. thanks for the details.. I will try to use AptioFix2 with the slide boot flag.. Without this boot flag I get a print,f error at early boot... slide=0 is fine or do I really have to use slide=N?   

Link to comment
Share on other sites

O.k. thanks for the details.. I will try to use AptioFix2 with the slide boot flag.. Without this boot flag I get a print,f error at early boot... slide=0 is fine or do I really have to use slide=N?

 

Once you get into the clover GUI, you need to go into the EFI shell and use the memmap command find the available region that has the largest space and calculate the slide value. You do that by taking the address of the region you found, subtract 0x100000 then divide by 0x200000. Now you have the slide value, you must make sure it is good. Do the calculation 0x100000 + (slide * 0x200000). That should give you the same address of the free area, if not add one to the slide or find another region and repeat.

 

EDIT: It's also ok if address calculated with the slide just offsets slightly into the region as long as there is still enough space for the kernel to load, usually around 0x12000 pages is good enough.

where do I get r4639?

I guess that's just a typo.. I guess it should properly read r4369...

 

Yes it's a typo, I fixed it, meant r4369.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.....

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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....

Link to comment
Share on other sites

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!

  • Like 4
Link to comment
Share on other sites

@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.  :surprised:

 

EDIT: Use AptioFix2 then.

  • Like 5
Link to comment
Share on other sites

@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.  :surprised:

 

EDIT: Use AptioFix2 then.

i always use AptioFix2 and no problems..

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 5
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

×
×
  • Create New...