Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

tluck
tluck
Posted
Posted (edited)

@vit9696 -

 

ah! cool.

 

i ran into this a few weeks ago testing IntelGraphicsDVMTFixup (it conflicted with AppleALC) (was using Lilu 1.1.0)

so now i have updated Lilu to 1.1.2 and these 2 kexts can both be used at the same time. 

 

my work around (a few weeks ago) was to put the patches from IntelGraphicsDVMTFixup into AppleALC since they are both patching AppleIntelSKLGraphicsFramebuffer.kext.

on the patch count - instead of counting the occurrences via Hexedit - i would set the patch count number to like 30 and see that LiLu would patch 7 of 30 occurrences then just fix the patch count and recompile.

 

-- 

 

good point Rehabman about patch count - was thinking that using a 0 for patch count may help future proof the patch? i cant think of a scenario when we want anything but all occurrences patched?

Edited by tluck
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

 

good point Rehabman about patch count - was thinking that using a 0 for patch count may help future proof the patch? i cant think of a scenario when we want anything but all occurrences patched?

 

Correct.

Link to comment
Share on other sites
Gigamaxx
Gigamaxx
Posted
Posted

What is not working? Please provide a boot.log or debug.log and picture. Also, did you use the ryzen kernel??

On Ryzen and clover compatibility.

 

I have tested using 4061, and a couple older versions I found from years back, I also did it with 4070 and here are some things I'vew noticed. Clover using legacy mode boot0af gives red panic. UEFI mode gives blinking cursor at top left of screen. This is without Bronya boot or kernel added.

 

If you replace the boot with the Bronya boot the screen menu is chameleon 2667 if using clover legacy boot0af mode. It acts like the Chameleon bootloader and as long as you have the kernel installed it starts to boot, but it has never finished boot process. I believe that clover is just tagging along for the ride and that the reason it Is not booting is because there are no Chameleon extra folders or other necessary injections taking place. I tried many boot attempts using every kernel flag possible, and used clover boot args as well. The only way to get it to boot using clover is to also add chameloen or Enoch which gives you the extensions, kernel, plist etc...

 

I tired to boot using a USB and clover 4070 and got the same red panic, but since there is no way to get to clover boot menu there are no options like f2, f4 etc. to get boot log. I don't think it is possible to get an error log during the boot process because it is using chameleon and not clover for the attempted boot. Red panic stops the process before it can start so there is no data to be had IMO. I'm no expert but I have tested the heck out of this over the last month or so with various clover builds.

 

When I'm able to boot successfully using clover/Chameleon nothing changes in About this Mac or IORegistry that is different f on booting with chameleon only. There is no clover effects or injections observed from my initial tests. Has anyone been able to load clover injections or fixes using Bronya boot and clover?

 

Question? Can you merge the boot files to get clover working or do completely new ones need to be written so that clover can recognize Ryzen CPUs and give us clover capabilities? There are several Sierra Ryzen users now that can't get pascal cards working and really need the clover solution to get the proper configuration. It would be nice to have clover options available for many reasons and fixes.

post-1753549-0-59633800-1495488230_thumb.jpg

post-1753549-0-84548700-1495488367_thumb.jpg

Link to comment
Share on other sites
gills83
gills83
Posted
Posted

Bronya is still there ......... :thumbsup_anim:  :w00t:  :yes:

 
Our brilliant coder Bronya took exactly 10 minutes to edit Clover so it works on Ryzen !!
 
After Chameleon, it is now the turn of Clover uefi.
 
 
thanks Bronya   :angel:
 
948216Photo0051.jpg
 
498039Photo0054.jpg
 
673462Photo0055.jpg
  • Like 5
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

I guess the osxaptio driver haven't update many years and i think it maybe some bugs with these new motherboards or chips and what a pity the damazr leave.

 

Now we may build a new driver to solve the memory allocation and this problem not only showed in Aptio BIOS but in almost all motherboards.

 

PS:Dont forge the Lowmenfix driver it may give some idea such as osxaptio-free2000 is osxaptiov2 + lowmenfix .

 

 

Don't forget that I helped dmazar with aptiofix, so it's not like there's no possibility of new driver, obviously I have been trying to gather information and maybe I'm close to writing something. Also, no, whatever you're talking about about those drivers is not what is happening, it's just a modified osxaptiofix that actually destroys a bunch of memory regions (has nothing to do with osxaptiofix2, maybe kinda like osxlowmemfix, but way worse). This method should only be used to know that your problem is memory fragmentation after you have exhausted all other methods just to boot - it should not be used for any sort of permanent use, let all to expect to get a stable system.

hmm interesting...

i had not tested -x in a while on my T460 SKL so i thought i would try:

 

- OsxAptioFix2Drv will NOT boot -x -v

- OsxAptioFixDrv does boot -x -v

 

I've discovered several bugs in both versions, they need to be fixed. I'm trying but I'm being pulled in a bunch of different directions currently.

 

As well there is no need to keep MatchOS and MatchBuild. Just make patch search to be unique.

 

MatchOS and MatchBuild are very useful features.

 

Yes, I agree, I was originally against as it actually causes more computations instead of less - not really saving much. But as I recall there were some patches that need to be changed differently for different versions so there was no other way to do that without distinguishing between the versions.

 

So we will never get Clover v3 hahahah

hahahahahahaha funny, do you have more jokes?

I'm obviously writing v3, I am just busy, I do this in my free time for nothing. Now, if there is anyone who would like to donate money to me through paypal so I can devote more time to doing this then please PM me and we can discuss and maybe get development moving faster.

 

You could specify 0 to replace all the occurrences, but specifying a correct value makes a faster patch.

As you mention we can specify 0 to catch all of them, or an accurate value.

Since this data lies near the end of the kext, there is probably no significant performance advantage to specifying anything other than zero.

The actual difference is probably nanoseconds no matter where in the kext/kernel. In-memory comparisons are quite fast since they are cache onto the CPU.

  • Like 5
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

Don't forget that I helped dmazar with aptiofix, so it's not like there's no possibility of new driver

Don't forget that it is OSS? :P I understand everything it does with the exception of a fix that is commented incorrectly. dmazar commented that removing the MemoryMap handoff on hibernate wake is equal to some other fix done on normal boot... though that fix on normal boot is long gone and the hibernate one persists. When removing it, RT var access does not work after hibernate wake, no clue why. I *could* imagine that due to flagging the old RT areas as a diff type, boot.efi saves and restores those old regions. When the MemoryMap handoff is present, boot.efi unmaps old RT pages and maps the new, that might be an issue, though that's pure speculation, I didn't look at it in at least a year.

 

EDIT: Yeah, obviously boot.efi doesn't save that memory, but the kernel.

Link to comment
Share on other sites
magnifico
magnifico
Posted
Posted

I'm obviously writing v3, I am just busy, I do this in my free time for nothing. Now, if there is anyone who would like to donate money to me through paypal so I can devote more time to doing this then please PM me and we can discuss and maybe get development moving faster.

 

 

Agree...i dont see the button donate ..for me no problem

Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted

Is not you the same dev partecipating in Ozmosis firmware born in Quo that was sell (= profit)? You partecipating for free? (whatever your answer is, who will believe you..?). This booter at least is opensource. I was reading those Topics seraching for the code.. so my idea is clear

  • Like 2
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

Don't forget that it is OSS? :P I understand everything it does with the exception of a fix that is commented incorrectly. dmazar commented that removing the MemoryMap handoff on hibernate wake is equal to some other fix done on normal boot... though that fix on normal boot is long gone and the hibernate one persists. When removing it, RT var access does not work after hibernate wake, no clue why. I *could* imagine that due to flagging the old RT areas as a diff type, boot.efi saves and restores those old regions. When the MemoryMap handoff is present, boot.efi unmaps old RT pages and maps the new, that might be an issue, though that's pure speculation, I didn't look at it in at least a year.

 

EDIT: Yeah, obviously boot.efi doesn't save that memory, but the kernel.

 

That was my point that there are plenty of people who understand the driver enough to be able to create a more stable version. The issue being not breaking what currently works and changing what doesn't to encompass fixing more firmwares. The memory regions are changed to MMIO so I can't possibly imagine why the kernel would think that it would need to remap these areas. By the very nature these regions are setup by hardware initialization. Also, only used for AptioFix2. AptioFix uses a relocation block where the regions are moved with the kernel and device tree, etc. So maybe there is more possibility with AptioFix, but I also have to imagine it would just try to take the regions that the firmware created, they will be created upon firmware init. Why would it save them? Does it save them? I've never checked that before.

 

EDIT: After a few minutes of reflection, I think that if there would be a problem with the kernel reloading these regions, that problem would probably manifest when the regions are moved to begin. Right?

 

Agree...i dont see the button donate ..for me no problem

 

Well mostly I meant so I wouldn't have to work as much and could focus more time on coding. I have to still make money to live. And anyone who would like to donate please PM me. Or really anyone who has contributed heavily to clover, we've all spent a lot of time developing this, none of us do this for profit. I have no intention of doing it for profit, but if I can get donations that allow me to focus more on it, of course I would like that.

 

ahh the old please donate funds to aid progress malarky..

 

also since this site is run as a commercial entity why do people donate ?

 

Who ever said that? I am only on this site because projectosx doesn't exist anymore, I have nothing to do with insanelymac. I wasn't extorting anyone, as I said, I am still writing it. My point was more to the fact if the progress isn't fast enough for you then donate money to me so I can focus more on development of v3 than, say, working as much trying to have food to eat. I'm also the one that does most of the administration on the repos and bug/request tickets. Don't be a jerk.

 

Is not you the same dev partecipating in Ozmosis firmware born in Quo that was sell (= profit)? You partecipating for free? (whatever your answer is, who will believe you..?). This booter at least is opensource. I was reading those Topics seraching for the code.. so my idea is clear

 

Yes clover is free and will remain free and open source. Won't comment on Ozmosis.

 

Why do you ask a question when you won't believe the answer? Argumentum ad hominem much? lolz

 

I think he was just pointing out the hypocrisy of calling me out for asking for donations when (apparently) he is part of the team that is trying to sell Quo. I don't even know if he does indeed have anything to do with Quo, nor do I care.

  • Like 7
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted

Argumentum ad hominem much? lolz

I apologize, but isn't.

 

If He is not a dev of that firmware, nothing to talk, but He behave like that. And if he is, I do not think he is so naive to work for free unless hesn't realizes (who belive this?) that someone already did, clearly. So why tell to others...
Sorry to be OT
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

That was my point that there are plenty of people who understand the driver enough to be able to create a more stable version. The issue being not breaking what currently works and changing what doesn't to encompass fixing more firmwares. The memory regions are changed to MMIO so I can't possibly imagine why the kernel would think that it would need to remap these areas. By the very nature these regions are setup by hardware initialization. Also, only used for AptioFix2. AptioFix uses a relocation block where the regions are moved with the kernel and device tree, etc. So maybe there is more possibility with AptioFix, but I also have to imagine it would just try to take the regions that the firmware created, they will be created upon firmware init. Why would it save them? Does it save them? I've never checked that before.

I don't have enough knowledge on XNU to make reliable assumptions. MMIO, in theory, should always be at the same address (after all drivers need to know where to access a device), though that obviously isn't necessarily the case with your converted pages. Might be related.

 

Well mostly I meant so I wouldn't have to work as much and could focus more time on coding.

Sorry mate, but do you really think for the twenty bucks or whatever one would donate you can hop off work? Does your boss let you just miss a few days? Doubt you can make enough to skip a month. ;)

 

I think he was just pointing out the hypocrisy of calling me out for asking for donations when (apparently) he is part of the team that is trying to sell Quo.

And if he is, I do not think he is so naive to work for free unless hesn't realizes (who belive this?)

I have been where you are and I talked {censored}... don't repeat that.

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

I don't have enough knowledge on XNU to make reliable assumptions. MMIO, in theory, should always be at the same address (after all drivers need to know where to access a device), though that obviously isn't necessarily the case with your converted pages. Might be related.

 

Sorry mate, but do you really think for the twenty bucks or whatever one would donate you can hop off work? Does your boss let you just miss a few days? Doubt you can make enough to skip a month. ;)

 

I have been where you are and I talked {censored}... don't repeat that.

 

MMIO is mapped by the option ROM of a device, the address configuration is in the PCI configuration space, so these areas can be placed any where in memory, usually at the top though. Anything counts to help me get by when I am trying to get a graduate degree and also working. I get to choose my schedule, so not having to work as much would obviously be helpful...

 

EDIT: Wording.

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

MMIO is mapped by the option ROM of a device, the address configuration is in the PCI configuration space, so these areas can be placed any where in memory

Not talking about 'fixed addresses' for any MMIO areas, but that the place in memory should not change between reboot cycles and especially not on hibernate wake, Apple might assume that.

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

Is not you the same dev partecipating in Ozmosis firmware born in Quo that was sell (= profit)? You partecipating for free? (whatever your answer is, who will believe you..?). This booter at least is opensource. I was reading those Topics seraching for the code.. so my idea is clear

 

i am, the project was a closed source hobby for 2 years and then a 3rd party wanted to licence and port it to their hardware and a small fee was negotiated. 

Edited by bs0d
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

building clover I noticed there seemed to be a lot of warnings, hundreds actually... being generated especially boot6 but also others is it something related to clover build command script or is it clover?

 

You can always add to the build options:

-Wall -Werror

That will give you all warnings as errors, my bet is they are probably not a big deal. I try to fix the ones that cause problems....

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

building clover I noticed there seemed to be a lot of warnings, hundreds actually... being generated especially boot6 but also others is it something related to clover build command script or is it clover?

Strange, I see only warnings from ld, and not numeroes, there are 4 - 10.

You can always add to the build options:

-Wall -Werror
That will give you all warnings as errors, my bet is they are probably not a big deal. I try to fix the ones that cause problems....

 

It's impossible. EDK2 can't be compiled with -Wall. Explanations were in developers mail-list.

-Werror is already present in the building process by default.

Except some warnings -Wno-.....

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