Jump to content

1,003 posts in this topic

Recommended Posts

2 hours ago, justin said:

 

That would be nice, thanks. Did you compile against the EDK from OpenCore’s repo? 

 

Im currently using the Emuvariableru timedxe.efi compiled against UDK 2018, it worked very well on my B360M-HDV mb, i wonder if the newer Variabledxe.efi from EDK is better. 

I tried Variabledxe.efi and it crashed OpenCore, corrupting the bios. Had to short the cmos reset pins on the motherboard to get it booting again. Not sure I'd qualify that as "better".

Share this post


Link to post
Share on other sites
Advertisement
3 hours ago, asstastic said:

I tried Variabledxe.efi and it crashed OpenCore, corrupting the bios. Had to short the cmos reset pins on the motherboard to get it booting again. Not sure I'd qualify that as "better".

Yes i had the same issue, until i tried - -pcd to compile like i said in my previous post, it  is working great now. 

Share this post


Link to post
Share on other sites
16 hours ago, justin said:

Yes i had the same issue, until i tried - -pcd to compile like i said in my previous post, it  is working great now. 

The - -pcd flag is essential, without it there is no emulation. The flag replaces the functionality that was previously in EmuVariableDxe before it was removed from the edk2 file tree...

 

Share this post


Link to post
Share on other sites
3 hours ago, dgsga said:

The - -pcd flag is essential, without it there is no emulation. The flag replaces the functionality that was previously in EmuVariableDxe before it was removed from the edk2 file tree...

 

Thanks for the info.

EmuVariableDxe is 27KB, while VariableDxe is 79KB, they both work for me,  VariableDxe seems better, like wake up a little bit faster. 

Share this post


Link to post
Share on other sites
Posted (edited)

I'm on Dell XPS 9560 laptop. I get a quick running list of kexts with kext versions listed next to it in verbose, then my computer panics and resets. (I have 3 kexts, the latest whatevergreen, lilu, and virtualsmc). Is there a setting in 0.0.3 to prevent that? I'm trying to boot into Catalina dp2.

Edited by nytr0

Share this post


Link to post
Share on other sites

Hello everyone,

 

I observe opencorepkg as an alternative to Clover, BUT.
If I may. As a computer scientist we are progressives.
The project is at its beginning, but as Clover becomes more and more friendly with frequent updates.
I have a hard time seeing the new features that the Opencore project brings, especially since the installation is far from easy and with limited hardware support at least at the current time. For me fragmentation divides talents but can sometimes have a blessing effect. I hope that will be the case for OpenCore.
Opencorepkg faeture
More hardware and configuration support
Easy installation
And brings better performance than these competitors Clover or Ozmosis.

This is my point of view.
Good continuation
Seyd

Share this post


Link to post
Share on other sites
Posted (edited)
13 hours ago, nytr0 said:

Is there a setting in 0.0.3 to prevent that? I'm trying to boot into Catalina dp2.

 

 

Yes there is, set PanicNoKextDump=YES, and add debug=0x100 keepsyms=1 -v boot args, you will be able to see the backtrace of Kernel Panic. 

To get Catalina running, you need latest Lilu and it’s plugins (whatevergreen, virtualsmc, applealc) compiled from source. If not, the iGPU will hang there. 

if you don’t have the the latest kexts, try disable iGPU in the BIOS, add -lilubetaall boot arg, you will boot. 

Edited by justin

Share this post


Link to post
Share on other sites
2 hours ago, seyd46 said:

As a computer scientist we are progressives.

 

A scientist should have no problem reading documents right, take a look at Docs/Configuration.pdf, you'll find something new that may hold back your opinion in this post

 

2 hours ago, seyd46 said:

especially since the installation is far from easy

 

The installation is easier than anything else if you read and understand the document.As for clover, there is basically no document, a graphic installer does not always mean easy. it is too hard to get the meaning of parameters in clover config.plist.

 

3 hours ago, seyd46 said:

with limited hardware support at least at the current time

 

i don't think so, the hardware supports depends on kexts, efi most of which clover uses are developed by the same members of opencore, e.g. whatevergreen, applealc, virtualsmc, apfsdriveloader.efi, aptiomemoryfix.efi.  i don't find there is differences between clover and opencore on hardware support. 

 

// PS: I was a clover user, still i am, but love opencore for it's simple structure and clean documents. no offense, just to clarify my feelings. 

 

 

Share this post


Link to post
Share on other sites
On 6/27/2019 at 2:49 PM, justin said:

@dgsga thank you a lot for the tip, i have successfully compiled the VariableRuntimeDxe.efi againt the OpenCorePkg/UDK. Sleep, reboot, shutdown all work on my Asrock B360M-HDV motherboard, here is what i did:


 


git clone https://github.com/acidanthera/audk UDK
cd UDK
source edksetup.sh
make -C BaseTools
build -a X64 -b RELEASE -t XCODE5 -p MdeModulePkg/MdeModulePkg.dsc -m MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf --pcd=PcdEmuVariableNvModeEnable=1
cp Build/MdeModule/RELEASE_XCODE5/X64/VariableRuntimeDxe.efi ~/Desktop/

 

this does not work, nvram still doesnt work with the z390 asus board

Share this post


Link to post
Share on other sites
Posted (edited)
5 minutes ago, errorexists said:

this does not work, nvram still doesnt work with the z390 asus board

 

Aha, then it's strange, im on B360M, this efi worked perfectly. without it, i don't get wroking shutdown, reboot or sleep/wake. 

 

by the way i use opencore v0.03, config.plist/LegacyEnable=NO

Edited by justin

Share this post


Link to post
Share on other sites
1 minute ago, justin said:

 

Aha, then it's strange, im on B360M, this efi worked perfectly. without it, i don't get wroking shutdown, reboot or sleep/wake. 

i keep getting the f1 post an no issues with clover an if i run nvram -p i get no out put using OpenCore

image.png.58ba2b8e45889f43a79e33e3a648aa0f.png

Share this post


Link to post
Share on other sites
8 minutes ago, errorexists said:

i keep getting the f1 post an no issues with clover an if i run nvram -p i get no out put using OpenCore

image.png.58ba2b8e45889f43a79e33e3a648aa0f.png

 

would you mind uploading your config.plist? (remove SN info)

Share this post


Link to post
Share on other sites
57 minutes ago, justin said:

 

would you mind uploading your config.plist? (remove SN info)

i dont think it would help as i have had pavo an others from the discord channel look at it an all say its good as i have read the docs an differences an applied all the correct info an opened a bug report an been closed byhttps://github.com/acidanthera/bugtracker/issues/397#issuecomment-504645693
 

 

Share this post


Link to post
Share on other sites
2 hours ago, Download-Fritz said:

@seyd46 Sorry, but criticism is hard to consider when there is no substance. What "hardware support" and "features" are lacking?

Possibly Z390 support for some that still have issues, (NVRAM Issues) But as i see by many posts on here the focus seems to be around booting windows, which leads me as to why people want to boot windows.

Surely making Opencore compatible with PC hardware to boot macOS would be more of a priority. and FYI constructive criticism is good and it's feedback.  

Share this post


Link to post
Share on other sites

My layout-id is 72, how would i put that in Opencore. 07200000?

Share this post


Link to post
Share on other sites

@MacFriedIntel Criticism is valueable so long as it is comprehensive enough to implement in the real world, yes.

As for Z390, it feels like there is a lot of confusion about the issue. It is not a plain "incompatibility" that needs "support added" for, from our current view it is either a design flaw in macOS (probably breaking the UEFI specification) or a severe bug in AMI's Aptio firmware. Basically, we tell UEFI to write a variable and it never comes back from it. This is not easy to debug and even if the issue was found, the solution might not be trivial.

Share this post


Link to post
Share on other sites
Posted (edited)
16 hours ago, Download-Fritz said:

@MacFriedIntel Criticism is valueable so long as it is comprehensive enough to implement in the real world, yes.

As for Z390, it feels like there is a lot of confusion about the issue. It is not a plain "incompatibility" that needs "support added" for, from our current view it is either a design flaw in macOS (probably breaking the UEFI specification) or a severe bug in AMI's Aptio firmware. Basically, we tell UEFI to write a variable and it never comes back from it. This is not easy to debug and even if the issue was found, the solution might not be trivial.

 

I appreciate the response, if this seems to be an APTIO issue, then wouldn't clover have the same issue, as Clover boots the Z390 mostly without complications these symptoms only seem to occur with Gigabyte and some Select ASUS Boards, All i ask is that some care and consideration is taken towards this and is noted and looked at in some depth, because future chipsets may end up based around the same Aptio Structure as the Z390 this could be an ongoing issue for OpenCore in general unless some time is spent looking for a possible solution. But a welcomed response and i thank you. 

Edited by MacFriedIntel

Share this post


Link to post
Share on other sites

I have noticed with @PMheart recent commit a structure change with renaming Tools to Utilities, will this be reflected in the Documentation as the macbuild.tool builds as per screenshot, but the structure in the documentation is still saying Tools?

 

Screenshot 2019-07-01 at 22.26.28.png

Share this post


Link to post
Share on other sites
9 minutes ago, MacFriedIntel said:

but the structure in the documentation is still saying Tools?

 

Tools in the structure in the documentation is for config.plist/Misc/Tools, which contains third party efi tools, like UEFI SHELL.efi, CLEAN NVRAM.efi, which will show up in the opencore boot menu if configured in the config.plis.  Utilities is for scripts (e.g. sign OC) . they were both called Tools, it was confusing before this change/commit.

Share this post


Link to post
Share on other sites
1 minute ago, justin said:

 

Tools in the structure in the documentation is for config.plist/Misc/Tools, which contains third party efi tools, like UEFI SHELL.efi, CLEAN NVRAM.efi, which will show up in the opencore boot menu if configured in the config.plis.  Utilities is for scripts (e.g. sign OC) . they were both called Tools, it was confusing before this change/commit.

Okay this makes sense, thanks

Share this post


Link to post
Share on other sites

@MacFriedIntel There is no such difference between Clover and OpenCore, there is only a difference between using and not using the EmuVariable driver (OC needs edk2's applying to all OSes, Clover has its own, which does not work with OC)

Share this post


Link to post
Share on other sites
35 minutes ago, Download-Fritz said:

@MacFriedIntel There is no such difference between Clover and OpenCore, there is only a difference between using and not using the EmuVariable driver (OC needs edk2's applying to all OSes, Clover has its own, which does not work with OC)

Clover uses EDK2 driver

  MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf

Clover.dsc line 253

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.

  • Similar Content

    • By Slice
      OK, 4988 released.
      Now, @vector sigma, what have we do to update translations?
    • By dracoflar
      So you've been reading the forum on this brand new boot loader called OpenCore hoping to try it out but you take one look at the configurations PDF and take a step back in shock at the complexity! Well if you've been feeling a bit intimidated by the DOCS well you've come to the right place:
       
      OpenCore Vanilla Desktop Guide
       
      If you have any issues or suggestions please feel free to comment
       
      - Your local neighbourhood Hackintosh Slav
    • By vit9696
      OpenCorePkg / Documentation / Configuration Template / Bugtracker   Discussion and installation should be done in a separate thread! This thread is for development only!
      Current status as of April 2019: Support for UEFI and DuetPkg (legacy) booting APFS and HFS+ compatibility ACPI patcher (adding, dropping, binary patching, relocation) Apple-compatible bless implementation DeviceProperties injection DataHub and SMBIOS generation Symbolic kext and kernel patcher Direct kext injection/patching/blocking within prelinkedkernel Installation/Recovery/FileVault 2 support  Configuration in config.plist with open documentation Simple boot picker for quick launch Direct boot from dmg images  
      Known defects live here.  
      For those, who are not familiar with the history, OpenCore is a project initially born in HermitCrabs Lab that unfortunately almost died before its birth. This release is both a rebirth and a complete rewrite of OpenCore, which brings a number of new ideas, and tries to preserve the smart moves incorporated by iNDi and his team. Other than that, I wish to express my deepest words of gratitude to Acidanthera and WWHC members: your participation was and remains the key for project success, and you are simply the best.
×