Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30960 posts in this topic

Recommended Posts

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

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

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

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.

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

apianti
apianti
Posted
Posted

I just said that so he would try and discover that most warnings are just warnings, like "don't look over the edge", but every one does that anyway - cause it's cool. Most of the warnings are actually in EDK, I try to fix the fixable ones in clover. As far as I remember there are few warnings that you can't get rid of with -Wall and they involve compiler defined macros not being defined (for the compiler not being used) and defaulting to zero. Apparently this is a problem, lol. I can't remember the others off the top of my head.

bronxteck
bronxteck
Posted
Posted

ok. if i build the existing local rev of clover. i do not get the warnings using micky's script but if i have the script pull edk and clover even though they are already at same revisions i get the warnings. i will attach a build log if you want to look at it. so maybe it is the script or edk.

CloverCommandBuildLog.txt

Slice
Slice
Posted
Posted

ok. if i build the existing local rev of clover. i do not get the warnings using micky's script but if i have the script pull edk and clover even though they are already at same revisions i get the warnings. i will attach a build log if you want to look at it. so maybe it is the script or edk.

Yes, there are numeroes warning building BaseTools. It is not our affair.

EDK2 developers said also "there are not our sources, not our license so we keep them as is. They works and let it be".

 Share
Go to topic listing
×
×
  • Create New...