AptioMemoryFix

[vit9696]

More or less, the fix for used addresses is working.

[apianti]

apianti, it is literally for aptio, and there is one more driver, which is also for aptio. So the naming if anything should stay.

In my opinion, it is better to maintain it externally from clover and just clone as edk and friends, because there is no reason only clover should use these drivers.

I am fine to give any of you commit access if necessary.

 

....So it works for no other UEFI firmware....? I think something more like that it is macOS boot fix is more appropriate. There's also no reason why clover would not backport this code. Why need to get ANOTHER repository working copy to pull and update.... UGH.

 

EDIT: Plus installer is complicated enough, introducing external dependencies that may not exist..... NO WAY.

[Guest]

better image quality

this latest report appears only in 10.13.2 17C2120

in 10.13.2 (17C89) I see only slide message related part

 

thank you for your work

 

 

 

[Slice]

Compilation successful but two similar warnings

/AptioMemoryFix/AptioMemoryFix/OUTPUT/X64/AsmFuncsX64.iii:224: warning: label alone on a line without a colon might be in error [-w+orphan-labels]

/AptioMemoryFix/AptioMemoryFix/OUTPUT/X64/AsmFuncsX64.iii:294: warning: label alone on a line without a colon might be in error [-w+orphan-labels]

Line 224

EntryPatchCodeJumpFromKernelPlaceholder

 

Line 294

DataBaseAdr

 

: needed?

[vit9696]

@Slice, thanks, fixed

 

@apianti, there might have been some misunderstanding between what I asked you to do. I asked you to import clover code dependencies during the build process from separate repositories, which other bootloaders could also do. There is no sane reason not to include the binaries in clover installer.

 

To my eyes this is preferred not due to clover "backporting" code or not, but due to clover returning the code back. There unfortunately already exists a precedent of clover supporting its own fork of UsbKbDxe changes, which are hard to get back due to various unrelated stuff. Clover is not alone and should not be alone, especially when such critical pieces are considered about.

 

As for non-aptio support, it is not unlikely that it exists, but since the main target (and test range) is aptio, I see no reason for officially declaring non-aptio support.

[Slice]

AptioMemoryFix works on my #1 without admonishments. NVRAM working too.

 

I think we can accept one more external module (HFSPlus.efi, apfs.efi, Shell.efi etc). It will be a headache for other Clover builders but no problem for me.

[apianti]

This is clover's code but slightly modified.... So you want to make code that was already included in clover, where it originated, external?

[WinstonAce]

Can anyone upload latest binary?

[vit9696]

This is clover's code but slightly modified.... So you want to make code that was already included in clover, where it originated, external?

Pretty much nobody was able to modify it/fix its issues in clover anyway after dmazar left. To me it is kind of convincing.

Also, regarding slightly, the issue is in details

[apianti]

Pretty much nobody was able to modify it/fix its issues in clover anyway after dmazar left. To me it is kind of convincing.

Also, regarding slightly, the issue is in details

 

I think you have some wrong information..... And anyone can suggest new code changes. I will happily give you write access to the repo. You never asked.

[vit9696]

I think you have some wrong information..... And anyone can suggest new code changes. I will happily give you write access to the repo. You never asked.

In case there were some language misunderstandings, I meant that it was not maintained, while remained within clover.

 

For me personally it is much easier to compile drivers with the native edk2 build system, not clover's scripts, since they perform a lot of tuning due to various specialties and edk2 patches required for the rest of the project. It is understandable, but for me it means that whenever I need to build clover I use a vm, so that it does not mess my environment. This was certainly not a best decision when you need to compile and test things every few minutes. So the point of having a separate package is definitely not because I had no write access to the clover's codebase, but because it was more convenient.

 

Also, when AptioFix was developed Clover was pretty much the only UEFI bootloader, i.e. the only project that really needed AptioFix. Now that changed, and even your upcoming CloverV3 would need AptioFix, and as you know, sharing the codebase among multiple projects is done via shared dependencies =)

[mhaeuser]

This is clover's code but slightly modified.... So you want to make code that was already included in clover, where it originated, external?

 

It makes absolute sense not having to clone the gigantic Clover svn repo to fetch/push AptioFix.

Also, well yes, Clover was the first to import it, but I remember quite lively how dmazar shared the code on POSX and basically said "yeah, import it, do whatever", so I would not strictly speak of "originate"

[apianti]

It makes absolute sense not having to clone the gigantic Clover svn repo to fetch/push AptioFix.

Also, well yes, Clover was the first to import it, but I remember quite lively how dmazar shared the code on POSX and basically said "yeah, import it, do whatever", so I would not strictly speak of "originate"

 

Yeah, I do mean originate.

 

EDIT: There's also no reason that you have to checkout the entire repository.

 

In case there were some language misunderstandings, I meant that it was not maintained, while remained within clover.

 

For me personally it is much easier to compile drivers with the native edk2 build system, not clover's scripts, since they perform a lot of tuning due to various specialties and edk2 patches required for the rest of the project. It is understandable, but for me it means that whenever I need to build clover I use a vm, so that it does not mess my environment. This was certainly not a best decision when you need to compile and test things every few minutes. So the point of having a separate package is definitely not because I had no write access to the clover's codebase, but because it was more convenient.

 

Also, when AptioFix was developed Clover was pretty much the only UEFI bootloader, i.e. the only project that really needed AptioFix. Now that changed, and even your upcoming CloverV3 would need AptioFix, and as you know, sharing the codebase among multiple projects is done via shared dependencies =)

 

You can build without the build system just fine, exactly how you did by making a different DSC/DEC to build only what you want... You just can't build the GUI without it since it generates build sources.

[tyufhl]

Can anyone upload latest binary?

binary.

AptioFixPlatform.zip

[mhaeuser]

EDIT: There's also no reason that you have to checkout the entire repository.

 

Not too firm with svn... you would at least need to dl the AF folder, the Library folder, the Include folder and change most of the dsc after that to compensate for the stuff you did not download

[THe KiNG]

Yeah, I do mean originate.

 

EDIT: There's also no reason that you have to checkout the entire repository.

 

 

You can build without the build system just fine, exactly how you did by making a different DSC/DEC to build only what you want... You just can't build the GUI without it since it generates build sources.

I really dunno why you try to be "suborn" so hard, all the original poster wanted to say is that he want it as a separate .pkg as all EDK pkg's are w/o importing and fixing various clover.dec apianti.dec mussroms.dec etc.dec

 

[apianti]

Alright. Whatever. That's exactly what's happening. Peace out guys.

[interferenc]

So I am getting a message that some slide values are not available and boot might fail. But it does not.

 

Is this something to worry about?

[mhaeuser]

So I am getting a message that some slide values are not available and boot might fail. But it does not.

 

Is this something to worry about?

It's fine

[Guest]

no it is a normal behavior, see some post above vit answer

 

So I am getting a message that some slide values are not available and boot might fail. But it does not.

 

Is this something to worry about?

[Balamut]

@apianti and others.

 

Sorry it took me a little longer then I wanted, but here is the Clover Folder, I've updated to the latest Clover and AptioFix but still stuck at ++++++++

 

Also for some odd reason, it restarts when it wakes up from the sleep.

 

Any help?

 

memmap.txt

 

CloverFolder.zip

[Guest]

Try to use aptiofix from vit9696 you can find in this thread

 

@apianti and others.

 

Sorry it took me a little longer then I wanted, but here is the Clover Folder, I've updated to the latest Clover and AptioFix but still stuck at ++++++++

 

Also for some odd reason, it restarts when it wakes up from the sleep.

 

Any help?

 

memmap.txt

 

CloverFolder.zip

            #15            

[Slice]

@apianti and others.

 

Sorry it took me a little longer then I wanted, but here is the Clover Folder, I've updated to the latest Clover and AptioFix but still stuck at ++++++++

 

Also for some odd reason, it restarts when it wakes up from the sleep.

 

Any help?

 

memmap.txt

 

CloverFolder.zip

Does the waking works with Clover's OsxAptioFix2Drv 4369?

[Balamut]

Hi Slice,

 

Sorry should have been more specific. Sleep only worked once for me on High Sierra and I can't remember what version it was, now it sleeps like a baby but instant reboot on the wake. 

Again sorry for this confusion.

 

Does the waking works with Clover's OsxAptioFix2Drv 4369?

[Slice]

Hi Slice,

 

Sorry should have been more specific. Sleep only worked once for me on High Sierra and I can't remember what version it was, now it sleeps like a baby but instant reboot on the wake. 

Again sorry for this confusion.

I am interesting in *AptioFix* dependency.