Jump to content
30960 posts in this topic

Recommended Posts

How so? You'd need to allocate the relocation blocks before boot.efi.

 

No, why would you? Overwrite AllocatePages(), call the original AllocatePages() and if it returns the appropiate error code (iirc EFI_OUT_OF_RESOURCES, but would need to check), just allocate elsewhere and store information about where it is now and where it should be copied to on kernel entry.

 

And backwards compatible to what? Lion? Who's running Lion that can't just use an older version of clover?

 

Yes, Lion and lower. I don't want this "use driver x for this version of macOS, use driver y for that version of macOS", I want one to rule them all.

Btw, vit checked boot.efi and found out that "slide=" is not available with safe mode. Imo now it's obvious which way to go

  • Like 1

No, why would you? Overwrite AllocatePages(), call the original AllocatePages() and if it returns the appropiate error code (iirc EFI_OUT_OF_RESOURCES, but would need to check), just allocate elsewhere and store information about where it is now and where it should be copied to on kernel entry.

 

How is that not allocating it before boot.efi, and how do you know you are not now allocating that region inside of where the slide was supposed to be? Figure out the slide and not allocate in that region, but how big is the region?? Then you go through all this to fail boot because there's a runtime region there........

 

Yes, Lion and lower. I don't want this "use driver x for this version of macOS, use driver y for that version of macOS", I want one to rule them all.

Btw, vit checked boot.efi and found out that "slide=" is not available with safe mode. Imo now it's obvious which way to go

 

Why is safe mode even needed? Why can't you just use -s and rebuild the cache? Or the recovery...? I could care less about Lion, it was released like seven years ago, and they can use AptioFix from an older package.

@apianti

So x99 rigs can’t have a proper working nvram stored?

Or is only an Asus x99 firmware problem in your opinion/experience?

Thank you

 

Unsure. X99 is one of the worst platforms, ASUS Z97 introduced a whitelist, which is probably also in ASUS X99, did you ever have working NVRAM? Because if you did then get the newest firmware and replace the Nvram modules with the ones from the working firmware and reflash, or downgrade. You can try writing to one of the whitelisted variables and see if that changes it (look at the solution for the UEFI topic for the NVRAM from vit9696, gives the whitelisted vars). Write to like BootOrder or something, by adding more to it.

 

EDIT: You are using the newest AptioFix2, right? Did you try setting slide?

How is that not allocating it before boot.efi

 

boot.efi is what is calling AllocatePages(), so how could it possibly be before boot.efi? o_O

 

and how do you know you are not now allocating that region inside of where the slide was supposed to be?

 

I don't, but I can use AllocatedPagesFromTop to be a bit safer. You are constantly outlining flaws with my approach, but forget that yours has very similiar ones, except that it breaks < Lion and safe mode. I prefer to not cut features just because "relocation feels wrong". Again, there is no perfect solution, but I see that mine is more likely to work for older OSes, more likely to support safe mode and more likely to find appropiate memory as BS_data and BS_code plainly do not matter. What if there is not a single region big enough to hold the estimation you've made, but it could if BS_* was gone?

  • Like 1

boot.efi is what is calling AllocatePages(), so how could it possibly be before boot.efi? o_O

 

I mean like allocating it before runtime, as in boot time. You still need to know how big the region needed for the kernel is or you could overwrite your relocation regions because they could be allocated in the region that was for the kernel.

 

I don't, but I can use AllocatedPagesFromTop to be a bit safer. You are constantly outlining flaws with my approach, but forget that yours has very similiar ones, except that it breaks < Lion and safe mode. I prefer to not cut features just because "relocation feels wrong". Again, there is no perfect solution, but I see that mine is more likely to work for older OSes, more likely to support safe mode and more likely to find appropiate memory as BS_data and BS_code plainly do not matter. What if there is not a single region big enough to hold the estimation you've made, but it could if BS_* was gone?

 

I never said relocation feels wrong, I said that it still has the exact same issues as not using it, which is that you need to know how much memory you need and where the slide is. So what is the point of doing that if you still need to do the same stuff plus more. If memory was just all allocated top down, then it would not be an issue at all, 0x100000 would be free for previous versions, and a slide should be pretty easy to get without doing anything. I have tested this on my Z77, Z170, Z270, virtual box, and QEMU with multiple firmwares. They all have almost all of the memory from 0x100000 to 0xE0000000 free (except for the virtual machines cause I only used 1GB of RAM).

 

EDIT: That is my solution, what I was suggesting is just a temporary stop gap to prevent failure on boot when the user does not supply a slide value.

EDIT2: Obviously, v2 is beyond screwed memory wise, and that is the real issue....

Most sexy kext of the day: AppleGPUWrangler

 

On my B85M-G / B85 chipset, since recent clover / optiofix2, I also can store efi variables without emuvariable.efi. 

 

I now tried Lilu and intelgraphicsfixup, but these extensions seem to do nothing at all, still firefox video is freezing while using nvidia + hd4600 at once

Most sexy kext of the day: AppleGPUWrangler

 

On my B85M-G / B85 chipset, since recent clover / optiofix2, I also can store efi variables without emuvariable.efi. 

 

I now tried Lilu and intelgraphicsfixup, but these extensions seem to do nothing at all, still firefox video is freezing while using nvidia + hd4600 at once

 

I think the problem with HD3000/4000 GPUs is to do with a reserved memory region setup for them but that is destroyed by AptioFix. I'm guessing you're fine if it's just NVIDIA right?

  • Like 1

@apianti

Yes i am using version included in latest clover R.4369

Without slide=128 i have printf error as i said before

 

And no, nvram never worked for me in different asus rigs (c612/x99) and in all firmware i have tested from asus

 

——————

 

EDIT: You are using the newest AptioFix2, right? Did you try setting slide?

Quote order is messed up... fml, I hate quoting here.

 

I mean like allocating it before runtime, as in boot time. You still need to know how big the region needed for the kernel is or you could overwrite your relocation regions because they could be allocated in the region that was for the kernel.

 

Yes, I admited that is a potential issue a few posts ago. :P

 

which is that you need to know how much memory you need and where the slide is. So what is the point of doing that if you still need to do the same stuff plus more.

 

You don't need to know how much memory is needed. When an overlap is encountered, boot must be aborted.

And no, ir's not "doing the same stuff plus more", it's simply temporarily moving regions and then moving them back (+ fix a handful of pointers) in contrast to implementing a MemoryMap scanner (dependent on an assumed kernel size), implementing a way to randomly generate a number, that that at the cost of backwards-compatibility, safe mode and possible available regions that only carry BS_*

 

I think the problem with HD3000/4000 GPUs is to do with a reserved memory region setup for them but that is destroyed by AptioFix. I'm guessing you're fine if it's just NVIDIA right?

 

Well, would you please push the fix? ;P

 

I never said relocation feels wrong

 

You said you did not want to use them with zero reasoning, so basically that was my interpretation.

Yes, I admited that is a potential issue a few posts ago. :P

 

You don't need to know how much memory is needed. When an overlap is encountered, boot must be aborted.

And no, ir's not "doing the same stuff plus more", it's simply temporarily moving regions and then moving them back (+ fix a handful of pointers) in contrast to implementing a MemoryMap scanner (dependent on an assumed kernel size), implementing a way to randomly generate a number, that that at the cost of backwards-compatibility, safe mode and possible available regions that only carry BS_*

 

You didn't see my edit about how that's not how I want the driver to work, I just want to use it as a stop-gap. Also those statements are conflicting, if you admitted that you could possibly allocate into the kernel region, then you do need to know how big it is and where it starts to avoid that... Sure you could protect against overlapping regions when you already know a region exists somewhere or is going to exist but not before... And depending on how random you want to get determines how difficult implementing a random generator is, I seem to recall that there is actually an RNG in EDK2. I think it uses RDRAND though so would only work for IB+.

 

EDIT: I said the same word twice but did not mean that word the second time.

 

Well, would you please push the fix? ;P

 

Yes, I will get to it eventually, I just don't feel very well. I think maybe that entire function might be able to be removed. There's a lot of dead and unneeded code, it really needs fixed.

 

You said you did not want to use them with zero reasoning, so basically that was my interpretation.

 

Oh, yeah, it's because of the overwriting problem, complexity, and way too much effort when it could be fixed in a much easier way by just making allocations more wisely and actually garbage collecting....

No, not really  :P

 

Hmmm.... I guess it's not like it's really not going to detect the integrated and not load the driver.... I'll look into it but I'm getting too sick to really do stuff now. I have a feeling it's to do with that region but I'll deal with it later. I think it's wrap myself in a blanket and watch some movies time. Medicine just making me weird....

  • Like 1

You didn't see my edit about how that's not how I want the driver to work, I just want to use it as a stop-gap. Also those statements are conflicting, if you admitted that you could possibly allocate into the kernel region, then you do need to know how big it is and where it starts to avoid that...

 

No, that is the point, that won't happen. It´s pretty much "hope for the best", which is the best result you can accomplish accross the AMI landscape without touching the flash chip.

Actually, our methods don't even contradict, if you have noticed.

  • Like 1

No, that is the point, that won't happen. It´s pretty much "hope for the best", which is the best result you can accomplish accross the AMI landscape without touching the flash chip.

Actually, our methods don't even contradict, if you have noticed.

 

But why wouldn't we choose the easiest method then if we are hoping for the best? Getting more complicated means that there's more chance for failure, not less. And some users solution might have to be flashing because of the nature of the firmware like those X99 with 300 PCIe and 4000 NVMe slots. Those things are like in my nightmares.

slide=0

Thanks! Its working! First time i have working Nvram with aptio 5 (x299)

 

@apianti @slice and other (Sry i didnt tracked exactly who maked it possible)

Thanks to all for the awesome work, thats a beatifull birthday gift for me :-)

 

Thanks Thanks Thanks!

Nvram work!!!

Finally we dont need emulated nvram anymore!

 

Cheers :-)

  • Like 4

Hm guys, I have sometimes beeper alert while rebooting. I have to power off then. Really strange. Afterwards the boot drive selection is wrong. 

 

...Or it just hangs on restart with maximum cpu....

 

EDIT: That only happens after I disabled HD4600 in the bios

 

Pretty nasty!

Hm guys, I have sometimes beeper alert while rebooting. I have to power off then. Really strange. Afterwards the boot drive selection is wrong. 

 

...Or it just hangs on restart with maximum cpu....

 

EDIT: That only happens after I disabled HD4600 in the bios

 

Pretty nasty!

 

Sounds like a firmware issue. Do you maybe have a setting to disable to integrated but also set the first initialized card and its set to integrated not PCIe? Also don't disable your HD4600, I will try to fix the issue with those reserved regions in the next few days. Are you sure you also have good graphics injection?

Thanks! Its working! First time i have working Nvram with aptio 5 (x299)

 

@apianti @slice and other (Sry i didnt tracked exactly who maked it possible)

Thanks to all for the awesome work, thats a beatifull birthday gift for me :-)

 

Thanks Thanks Thanks!

Nvram work!!!

Finally we dont need emulated nvram anymore!

 

Cheers :-)

 

It was more vit9696 and Download-Fritz. But glad you got it working!

  • Like 1

Sounds like a firmware issue. Do you maybe have a setting to disable to integrated but also set the first initialized card and its set to integrated not PCIe? Also don't disable your HD4600, I will try to fix the issue with those reserved regions in the next few days. Are you sure you also have good graphics injection?

 

No, it worked fine with the old aptiofix2 and older clover and disabled HD4600 graphics in the bios.  It beeps just before restart. It is like a protection beep against memory corruption? Sounds nasty, lot of beeps.

 

Yes injection is done properly. I now enabled hd4600 again (primary gfx is nvidia PCIe), and then set the hd4600 to a connector-less ig-platform-id. So it does not appear as opencl render anymore. Now the restarting works normally again.

 

Let me know if I can do some tests.

 

BTW: I re-tried with emuvariable.efi, no change, still beeping (hd4600 disabled).

Also re-tried aptiofix1-WTH, no change.

one question: if I have a IGPU device and ig-platform-id set in my ACPI, can I drop that whole device and its references only using clover, so I can then inject another ig-platform-id using clover?

 

Since clover won't overwrite the existing ig-platform-id... Or do I have to make an acpi patch in clover then?

No, it worked fine with the old aptiofix2 and older clover and disabled HD4600 graphics in the bios.  It beeps just before restart. It is like a protection beep against memory corruption? Sounds nasty, lot of beeps.

 

Yes injection is done properly. I now enabled hd4600 again (primary gfx is nvidia PCIe), and then set the hd4600 to a connector-less ig-platform-id. So it does not appear as opencl render anymore. Now the restarting works normally again.

 

Let me know if I can do some tests.

 

BTW: I re-tried with emuvariable.efi, no change, still beeping (hd4600 disabled).

Also re-tried aptiofix1-WTH, no change.

one question: if I have a IGPU device and ig-platform-id set in my ACPI, can I drop that whole device and its references only using clover, so I can then inject another ig-platform-id using clover?

 

Since clover won't overwrite the existing ig-platform-id... Or do I have to make an acpi patch in clover then?

 

IDK is your integrated still be recognized by macOS? Are you disabling the HD4600 or changing from integrated default to PCIe default? Why won't clover override the existing ig-platform-id? It will inject whatever you put in the key's value, or it should.

 

EDIT: Those drivers are in r4369, there's no need to go trying other drivers, the AptioFix2 in r4369 is the ONLY fix anyone should be trying to use at this point.

IDK is your integrated still be recognized by macOS? Are you disabling the HD4600 or changing from integrated default to PCIe default? Why won't clover override the existing ig-platform-id? It will inject whatever you put in the key's value, or it should.

 

EDIT: Those drivers are in r4369, there's no need to go trying other drivers, the AptioFix2 in r4369 is the ONLY fix anyone should be trying to use at this point.

 

Is it the same like you linked here before?

@DF,

 

I changed the windows build because it was broken, it wasn't actually building some stuff or the firmware, lol. I also tried to set optimization for size..... It did not change the size of one file even though it clearly was used during the build. Apparently VS sucks at optimizing for size, or not all sources are being optimized (maybe assembly)?

@apianti

I have done a minimal sort of empiric debug on my system

With latest aptiofix2 and emuvariable64uefi driver installed I can boot with or without any slide parameters

deleting emuvariable64uefi I can boot only with slida=128 or greater

without it compares error "does printf work?"

 

for the sake of test I have also used a old aptiofix2 and it has same beahviour

 

I have no installed RCscript on any volume

 

obviously Nvram does not work after resetting my system

×
×
  • Create New...