Jump to content
vit9696

AptioMemoryFix

484 posts in this topic

Recommended Posts

Advertisement

@Zenith432, yes, it makes good sense to me. Committed.

 

@fabiosun, thx for the report.

 

@Download-Fritz, in my opinion, it is likely not worth it. Without the option it will hardly be able to boot anyway.

Share this post


Link to post
Share on other sites

What do you mean? There are no debug lines in AptioMemoryFix. There are warnings, which you may obviously see in verbose (-v) mode. This is what boot.efi and the rest do.

Share this post


Link to post
Share on other sites

@Zenith432, yes, it makes good sense to me. Committed.

 

@fabiosun, thx for the report.

 

@Download-Fritz, in my opinion, it is likely not worth it. Without the option it will hardly be able to boot anyway.

with the latest commit, something is broke

Building ... /Users/henrybrock/Desktop/AptioFix/edk2/AptioFixPkg/Platform/AptioMemoryFix/AptioMemoryFix.inf [X64]
"ld" -arch x86_64 -u __ModuleEntryPoint -e __ModuleEntryPoint -preload -segalign 0x20 -pie -all_load -dead_strip -seg1addr 0x240 -map /Users/henrybrock/Desktop/AptioFix/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64/AptioFixPkg/Platform/AptioMemoryFix/AptioMemoryFix/DEBUG/AptioMemoryFix.map -o /Users/henrybrock/Desktop/AptioFix/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64/AptioFixPkg/Platform/AptioMemoryFix/AptioMemoryFix/DEBUG/AptioMemoryFix.dll  -filelist /Users/henrybrock/Desktop/AptioFix/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64/AptioFixPkg/Platform/AptioMemoryFix/AptioMemoryFix/OUTPUT/static_library_files.lst
Undefined symbols for architecture x86_64:
  "_gRtShimsDataEnd", referenced from:
      _MOStartImage in lto.o
  "_RtShimGetNextVariableName", referenced from:
      _MOStartImage in lto.o
  "_RtShimSetVariable", referenced from:
      _MOStartImage in lto.o
  "_RtShimSetTime", referenced from:
      _MOStartImage in lto.o
  "_RtShimGetNextHighMonoCount", referenced from:
      _MOStartImage in lto.o
  "_RtShimResetSystem", referenced from:
      _MOStartImage in lto.o
  "_RtShimGetTime", referenced from:
      _MOStartImage in lto.o
  "_RtShimGetWakeupTime", referenced from:
      _MOStartImage in lto.o
  "_RtShimSetWakeupTime", referenced from:
      _MOStartImage in lto.o
  "_RtShimGetVariable", referenced from:
      _MOStartImage in lto.o
  "_gRtShimsDataStart", referenced from:
      _OvrSetVirtualAddressMap in lto.o
      _MOStartImage in lto.o
ld: symbol(s) not found for architecture x86_64
make: *** [/Users/henrybrock/Desktop/AptioFix/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64/AptioFixPkg/Platform/AptioMemoryFix/AptioMemoryFix/DEBUG/AptioMemoryFix.dll] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/henrybrock/Desktop/AptioFix/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64/AptioFixPkg/Platform/AptioMemoryFix/AptioMemoryFix]


build.py...
 : error F002: Failed to build module
	/Users/henrybrock/Desktop/AptioFix/edk2/AptioFixPkg/Platform/AptioMemoryFix/AptioMemoryFix.inf [X64, XCODE5, RELEASE]

- Failed -
Build end time: 13:46:12, Jan.20 2018
Build total time: 00:00:02

Share this post


Link to post
Share on other sites

Agh, did not realise that Clover still used old naming style. Fixed.

 

fabiosun, well, only half of that is from AptioFix (in particular, only the slide unavailable part), and to my eyes it is useful enough to be left enabled by default.

Since if one still has issues when booting and decides to use a custom slide, he will at least be able to see which ones definitely to avoid.

 

The rest is from boot.efi, and it is pretty much the initialisation issue I described on the previous page. You are best to patch boot.efi, if this annoys you (will require some reversing and asm knowledge).

A proper fix (I checked PE docs, and it looks like uninitialised section should be zero-filled) would likely be to ensure that uninitialised boot.efi section portions are zero-filled.

Share this post


Link to post
Share on other sites

Ok fixed the build issue from last commit, just had to remove the cached build config and rebuild. Updated my build script to check if EDK2 has any repo updates and also to remove cached build config if no updates are detected.

 

Ok now the script shows spinning progress while running, requested by users

 

AptioMemory_Builder.sh.zip

Share this post


Link to post
Share on other sites

Created a repo on Github to be able to track changes

https://github.com/Pavo-IM/AptioMemFix

I tried your script and removed from it &>/dev/null to see errors.

It still does not compile with such errors:

 

 

build.py...

 : error 7000: Failed to execute command

make tbuild [/users/sergeyls/Desktop/AptioFix/edk2/Build/AptioFixPkg/DEBUG_XCODE5/X64/MdePkg/Library/BaseLib/BaseLib]

 

 

build.py...

 : error F002: Failed to build module

/Users/sergeyls/Desktop/AptioFix/edk2/MdePkg/Library/BaseLib/BaseLib.inf [X64, XCODE5, DEBUG]

 

Share this post


Link to post
Share on other sites

 

I tried your script and removed from it &>/dev/null to see errors.

It still does not compile with such errors:

 

 

build.py...

 : error 7000: Failed to execute command

make tbuild [/users/sergeyls/Desktop/AptioFix/edk2/Build/AptioFixPkg/DEBUG_XCODE5/X64/MdePkg/Library/BaseLib/BaseLib]

 

 

build.py...

 : error F002: Failed to build module

/Users/sergeyls/Desktop/AptioFix/edk2/MdePkg/Library/BaseLib/BaseLib.inf [X64, XCODE5, DEBUG]

 

Thanks The problem is solved. I just copied nasm into the folder /Library/Developer/CommandLineTools/usr/bin/

Share this post


Link to post
Share on other sites

Sorry for the newb question,

 

But will this driver help to reduce the graphics glitches on the HD3000? I think is memory related. If I'm not doing anything I don't get the horizontal lines/glitches.

Share this post


Link to post
Share on other sites

Just made a docker container that will auto build AptioMemoryFix using EDK2. Great thing about this is that it can run on any OS that has Docker installed. This is using CentOS 7 with GCC 4.8 with clang to build.

 

If you would like to use this make sure you have Docker installed and do the following commands.

Initial run:

docker pull pavo/aptiofix_builder

docker run -it -v $HOME/Desktop/AptioFix_Build:/root/AptioFix_Build --name AptioFixBuild pavo/aptiofix_builder

docker commit AptioFixBuild initial_build

docker rm AptioFixBuild

This will create a folder on the users Desktop and mount it into the docker container, once the build process is done it will copy the EFI modules into that folder.

 

 

To re-build ie.... if AptioMemory, EDK2 has had changes do the following commands:

docker run -it -v $HOME/Desktop/AptioFix_Build:/root/AptioFix_Build --name AptioFixBuild initial_build 

This will check to see if there is any updates to AptioMemoryFix repo (vit9696), EDK2 repo and update it if there is. It will also rebuild the EFI modules.

 

Default build is both DEBUG and RELEASE. If you want to build either a RELEASE or a DEBUG version do the following commands:

docker run -it -v $HOME/Desktop/AptioFix_Build:/root/AptioFix_Build --name AptioFixBuild --entrypoint /root/setup.sh initial_build RELEASE

or:

docker run -it -v $HOME/Desktop/AptioFix_Build:/root/AptioFix_Build --name AptioFixBuild --entrypoint /root/setup.sh initial_build DEBUG

Share this post


Link to post
Share on other sites

Hello everyone

 

How much time should take the building of AptioFix?

On my little 2010 MacBook Air, it has been running for 8 hours and it is still building the DEBUG version, should I worry or consider as normal processing time considering this machine's capacity?

Share this post


Link to post
Share on other sites

Hello everyone

 

How much time should take the building of AptioFix?

On my little 2010 MacBook Air, it has been running for 8 hours and it is still building the DEBUG version, should I worry or consider as normal processing time considering this machine's capacity?

On my comp #1 it requires 57 seconds. I don't think your book is 200 times slower.

Share this post


Link to post
Share on other sites

Hi,

 

I updated the details about boot.efi logging. This time I think I got it right:

http://www.insanelymac.com/forum/topic/331381-aptiomemoryfix/page-7?do=findComment&comment=2572819

 

The missed part in the previous description was bootercfg nvram variable, which allows one to configure boot.efi behaviour just like boot-args do to XNU.

May somebody from Clover team add an interface to it? It will be handy when debugging the issues.

 

Additionally I fixed several issues in AptioMemoryFix, which could have caused boot failures on certain motherboards. Hopefully it works fine for more people now :)

Share this post


Link to post
Share on other sites

RC8 Works great here

 

Edit**

I can confirm now the r8 AptioMemoryFix works UEFI on Snow Leopard 10.6.8 and  Mac OS X Lion 10.7  :D

Attaching boot log

Thank you very mutch !

post-951341-0-81955000-1517357483_thumb.png

Clover Boot Log-10.6.txt.zip

Clover Boot Log-10.7.txt.zip

Share this post


Link to post
Share on other sites

AptioMemoryFix works great on Dell latitude E6230(Native NVRAM works!).

AptioInputFix: Prevented me from enter clover GUI(timeout=0), also Apple's Boot Key combination never works!

Anyway, sometimes, when I reboot, I got a prohibited boot icon. Not sure which one caused it but pretty sure that it caused by one of the driver in AptioFix. Debug version write something like Found 2/3 keys... LoadImage...

Share this post


Link to post
Share on other sites

on my rig, latest aptiomemoryfix doesnt work, "printf work?". 

if above 4g decoding is enabled in bios, i must use slide=128 to get it boot

if 4g disabled, i dont need slide=128 to boot.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×