Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

Hey,

 

found maybe some new investigation regarding AMD no sleep problem.

 

Seems that the Intel HD Framebuffer only is required, so the intel gfx device is not detected, but the framebuffer (in my case azul) is loaded. The sleep then still works, so it seems that the azul / capri framebuffer kext alone are responsible for a working sleep mode for AMD gfx?

 

edit: I forgot to mention that sleep does not work, if you also remove the Intel framebuffer... so is it right to assume that the AMD gfx bios initialization theory is wrong, but instead there is some code in that framebuffer which makes sleepmode working for amd?

 

AMD sleep wake needs IGPU and connection to monitor.    If no monitor is connected to IGPU no Wake.    

 

I have been toying with a i3 7350K and have had issues getting HD 630 to work.   I used fake ID 0x19120001 for Skylake ( its J=Kaby Lake) and got some interesting results.    Mork may have encountered this before.    The PCI slot says 1 lane in About this Mac.

 

post-1753549-0-65097500-1500737262_thumb.png post-1753549-0-20657300-1500737316_thumb.png post-1753549-0-36613400-1500737336_thumb.png

 

This is with IGPU partially supported.

 

post-1753549-0-07634900-1500737285_thumb.png

Ioreg. RX 480 no igpu.zip

  • Like 1
Link to comment
Share on other sites

I have two windows 10 UEFI in fact, on my PC the logo is present but on my laptop not  :angel:

I reinstalling Windows 10 UEFI in my laptop and now the Logo is the HP Logo :hysterical:  :rofl:

Now is Updated in Progress 

 

 

hello

 

the boot is the same

 

boot.efi

 

from Mac OS x

 

only thing is diff

 

is the efi.drivers

 

maybe not the same ... uefi and legacy boot

 

is a no sense telling someone boot in legacy with a efi bios ..

 

i see this many times here in this topic

 

good hack

Link to comment
Share on other sites

hello

 

the boot is the same

 

boot.efi

 

from Mac OS x

 

only thing is diff

 

is the efi.drivers

 

maybe not the same ... uefi and legacy boot

 

is a no sense telling someone boot in legacy with a efi bios ..

 

i see this many times here in this topic

 

good hack

Yes its correct

my HP Bios as

Legacy boot

CSM/UEFI or UEFI Only

 

Now all is good with UEFI Only :)

 

EDIT***

But UEFI native no CSM the verbose boot is deform , when the second stage boot apear the screen is perfect  :angel_not:

So I am return to CSM /UEFI, I need my verbose boot some times.

Link to comment
Share on other sites

OsxAptioFixDrv64 from back around page 492, was there a fix for version 1 of this driver about the memory exceeding allocation relocation block?   AptioFix2 works fine but its using reloc block=no.  Does that make any difference?  I know my shutdown is way faster using the original driver versus aptiofix2 but it works fine.  I just wanted to know if there were versions out there for Aptiofix v1 that fixed this reloc block size?  Maybe bad searching on my part because i thought RehabMan had posted some different reloc block sizes?

 

This is for an Asus maximus VIII Hero Alpha, skylake Motherboard.

 

Thanks

 

Edited:

 

Should have searched better found the fix changed CsrActiveConfig from 0x3 to 0x67.  Was the original AptioFixDrv Reloc Allocation Relocation size increased then? 

 

Using AptioFIx2Drv sets reloc block to "yes" and AptioFixDrv original sets reloc block "no" is there any difference here?  Only difference I can observe is the original AptioFixDrv gives me much faster shutdown.

Link to comment
Share on other sites

AptioFix2 does not relocate the allocation for the kernel, where AptioFix does. Use whichever works. There are modified versions, DO NOT USE THEM, because they free random regions of memory, you don't want this.

  • Like 1
Link to comment
Share on other sites

AptioFix2 does not relocate the allocation for the kernel, where AptioFix does. Use whichever works. There are modified versions, DO NOT USE THEM, because they free random regions of memory, you don't want this.

This tip is for the all Hacks (old and new ones)?

 

Thanks

Link to comment
Share on other sites

This tip is for the all Hacks (old and new ones)?

 

Thanks

 

Unsure what you mean? Only use AptioFix, AptioFix2, or LowMemFix. Those other drivers are not a good idea, if they were, I would have implemented it in the drivers already. They came about from a proof of concept and conversation I had with Nick on sf.net. They are terrible drivers intended only to help me resolve the issue, which actually was never really resolved. I had another idea a minute back to try to reserve the region first, then free region before actual boot, appears this would be the best solution. However, I am not in the best of health and can't really get stuff done as I'd like.... My computer was also stolen, so I lost everything I was developing....

 

EDIT: If someone would like to modify those drivers to achieve this here is a basic algorithm:

 

1. Start with slide=0 and a max region size, probably 0x20000 pages is good.

2. Get memory map.

3. Search memory map for free region(s). Calculate the slide that each region would require [slide = (address - 0x100000) / 0x200000]. Notice that this can put you above or below the starting address, so you have to make sure it's still inside the region and adjust the page count accordingly. Choose the lowest slide with the largest free region, the first region with max pages should be chosen and searching can stop. Actually the memory map may not be in order...

4. Allocate this region to prevent it from being used.

5. Add (or modify) slide=X argument for entry if it's boot.efi, where X is the slide that was just calculated in step 3.

6. Free this region when a loader is started.

 

This driver would need to be specially loaded before any other drivers so the drivers loading would need to be modified - it would also help if the driver was loaded at top of memory to prevent from using prime real estate in low memory.

  • Like 2
Link to comment
Share on other sites

I've mean that we shouldn't use these drivers in the new Hardwares as @oSxFr33k has mentioned (Skylake board)? Or in the old Hardwares as mine (Ivy Bridge), if these drivers can be dangerous.

Link to comment
Share on other sites

I've mean that we shouldn't use these drivers in the new Hardwares as @oSxFr33k has mentioned (Skylake board)? Or in the old Hardwares as mine (Ivy Bridge), if these drivers can be dangerous.

 

Yeah, do not use them unless it's entirely a last resort, legacy booting should be attempted first. It's very likely they will result in unintended side effects, especially if the region is needed for a device. Really even LowMemFix probably shouldn't be used as it also just releases low memory regions, however it's for specific hardware that is known not to have an issue with releasing these regions...

  • Like 3
Link to comment
Share on other sites

Yeah, do not use them unless it's entirely a last resort, legacy booting should be attempted first. It's very likely they will result in unintended side effects, especially if the region is needed for a device. Really even LowMemFix probably shouldn't be used as it also just releases low memory regions, however it's for specific hardware that is known not to have an issue with releasing these regions...

Thank you so much @apianti, I'm gonna do this here right now!  ;)

Link to comment
Share on other sites

I've mean that we shouldn't use these drivers in the new Hardwares as @oSxFr33k has mentioned (Skylake board)? Or in the old Hardwares as mine (Ivy Bridge), if these drivers can be dangerous.

On my skylake board osxaptiofix2 works fine.
Link to comment
Share on other sites

On my skylake board osxaptiofix2 works fine.

I used osxaptiofix2 on my skylake but I recently switched to OsxAptioFixDrv-64 and it seems to be working better that the other one (at least for me).

I also used osxaptiofix2 on my Ivy-Bridge and it started to acting up specially when I used RC Scripts, the computer couldn't boot I had to reset the BIOS. After running some tests I noticed that the RC Script was causing the problem in combination with osxaptiofix2 so I switched form osxaptiofix2 to OsxAptioFixDrv-64 instead (On both systems). I still don't use RC Scripts on my IvyBridge (Second system in my signature) but it has no problem on my SkyLake.

Link to comment
Share on other sites

@slice,

 

I was referring to the modified drivers, the originals should work fine. However, I know that AptioFix2 has a bug in it somewhere determining the page count(s) but I can't seem to figure out where. As you shouldn't have a problem ever allocating the memory with AptioFix2, yet it sometimes tries to allocate less than it needs resulting in some users forced to use AptioFix.

 

@DF,

 

Well because the problem is that for some reason firmwares have started randomizing the address where drivers are loading. So instead of the drivers getting clumped together at the top or bottom of memory they are randomly dispersed, effectively fragmenting the memory beyond the ability to have a region big enough to load the kernel space. There is of course no reasonable fix for firmwares that do this and are loading lots of device option ROMs, that would involve modifying the firmware and as far as I know only appears to be X99 related, I haven't seen this problem in other platforms. Of course it could just be that X99 mobos happen to be able to support a lot of devices.... But this problem started appearing with that platform and has never really went away, I'm guessing that aptio firmwares were changed around this point to allocate memory differently.

 

EDIT: Should also point out that the more EFI drivers you have in drivers folder loading and more kexts that are injected, the more likely you are to get a failed boot due to not a large enough free region.

EDIT2: The advice - if you are getting this error, remove as many EFI drivers and injected kexts as possible. Then try the other AptioFix, then try legacy boot. Then probably just give up and cry.... lol

  • Like 2
Link to comment
Share on other sites

I used osxaptiofix2 on my skylake but I recently switched to OsxAptioFixDrv-64 and it seems to be working better that the other one (at least for me).

I also used osxaptiofix2 on my Ivy-Bridge and it started to acting up specially when I used RC Scripts, the computer couldn't boot I had to reset the BIOS. After running some tests I noticed that the RC Script was causing the problem in combination with osxaptiofix2 so I switched form osxaptiofix2 to OsxAptioFixDrv-64 instead (On both systems). I still don't use RC Scripts on my IvyBridge (Second system in my signature) but it has no problem on my SkyLake.

My case, rare(random) failed boot(maybe shorted enter osx,apple logo stop)

All My build switched osxaptiofixv2 to osxaptiofixv2-free2000+apianti's slide method.

free2000 supported single mode correctly and stable(never see failed boot case) for all my build. Long time ago, i reported this true on bug/report thread.

 

As result, i dont worry aptio issue.

 

나의 LG-F800S 의 Tapatalk에서 보냄

  • Like 1
Link to comment
Share on other sites

My case, rare(random) failed boot(maybe shorted enter osx,apple logo stop)

All My build switched osxaptiofixv2 to osxaptiofixv2-free2000+apianti's slide method.

free2000 supported single mode correctly and stable for all my build. Long time ago, i reported this true on bug/report thread.

 

나의 LG-F800S 의 Tapatalk에서 보냄

So is it safe for me to use RC Scripts on my IvyBridge again? I really don't like to open the case again because the clear CMOS jumper is beneath the GPU and I have to take it out to reset the BIOS. :rofl:

Link to comment
Share on other sites

So is it safe for me to use RC Scripts on my IvyBridge again? I really don't like to open the case again because the clear CMOS jumper is beneath the GPU and I have to take it out to reset the BIOS. :rofl:

My skylake laptop and skylake desktop(pentium) use rc script for unsupported native nvram on bios.

 

I never see cmos issue. Try it. But not sure your case

 

나의 LG-F800S 의 Tapatalk에서 보냄

  • Like 1
Link to comment
Share on other sites

My case, rare(random) failed boot(maybe shorted enter osx,apple logo stop)

All My build switched osxaptiofixv2 to osxaptiofixv2-free2000+apianti's slide method.

free2000 supported single mode correctly and stable(never see failed boot case) for all my build. Long time ago, i reported this true on bug/report thread.

 

As result, i dont worry aptio issue.

 

My whole point is that you should NOT use that modified driver. It's just freeing memory without regard to what that memory is...

 

 

So is it safe for me to use RC Scripts on my IvyBridge again? I really don't like to open the case again because the clear CMOS jumper is beneath the GPU and I have to take it out to reset the BIOS. :rofl:

 

You really only need the RC scripts if you want to like save boot.log, mount ESP by default, or don't have working NVRAM and use emulation. Otherwise you don't need them.

  • Like 3
Link to comment
Share on other sites

My whole point is that you should NOT use that modified driver. It's just freeing memory without regard to what that memory is...

 

 

 

You really only need the RC scripts if you want to like save boot.log, mount ESP by default, or don't have working NVRAM and use emulation. Otherwise you don't need them.

Thanks for the info. So I won't be needing the RC Scripts on my IvyBridge because I don't need any of these on my test rig. :)

Link to comment
Share on other sites

AMD sleep wake needs IGPU and connection to monitor. If no monitor is connected to IGPU no Wake.

Hm, no, I did :

 

- Set Igpu As primary

- connected monitor to amd

- Removed all Intel kexts except Azul frame buffer

 

In result, Igpu is not available in macos, but sleep wakeup works. Azul frame buffer is loaded.

 

Now if I also remove Intel Azul frame buffer, sleep does not work.

 

So I conclude in that frame buffer there must be some essential code to make wakeup work. If that code could be run without igpu as primary, maybe sleep wakeup still would work?

 

Edit: nvm, these are too individual problems, I didn't realize. The Azul frame buffer is needed to enter sleep, but not for wakeup.

 

What, if clover could display on secondary gfx device (if only there a monitor is attached)? Is that possible?

Link to comment
Share on other sites

That's because the legacy layer (CSM) is limited to few 4:3 resolutions (may vary for the different boards). The UEFI native mode has no such limitations. The only requirement is the Video BIOS to be UEFI - compatible as well (mostly for all external video cards).

 

Sent from my MI 5s using Tapatalk

Link to comment
Share on other sites

×
×
  • Create New...