Andres ZeroCross Posted July 13, 2019 Share Posted July 13, 2019 14 hours ago, vit9696 said: Generally that's fine. It should not change unless /S/L/E kexts change. > I reboot My PC and boot to openCore, Do not do that. Please boot straight to UEFI Shell (add it as EFI/BOOT/BOOTx64.efi) then load OpenCore. I have a suspect that EFI file system drivers are faulty, so better not to reboot. Oke maybe this is stupid question. I have BOOT to OpenCoreShell directly,, then i want to follow this step "— copy this file through UEFI shell to some other place". You mean i need to copy "PrelinkedKernel" right? But in openCore shell, i only can see EFI partition only. FS0:, FS1:, FS2:, BLK1, BLK2-BLK21. None of them about macOS partition. Several letter just for EFI Partition. I have 3 OS in UEFI so i have 3 EFI Partition. How can i copy PrelinkedKernel from OpenCoreshell if i can't access the macOS system partition Link to comment Share on other sites More sharing options...
vit9696 Posted July 13, 2019 Share Posted July 13, 2019 You can do the following: load ApfsDriverLoader.efi map -r Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted July 13, 2019 Share Posted July 13, 2019 (edited) 26 minutes ago, vit9696 said: You can do the following: load ApfsDriverLoader.efi map -r I am in shell, and i am in macos partition. But i can't go to System/Library/PrelinkedKernel. No directory to System/Library/PrelinkedKernel or System/Library/Extensions. It's look hidden, catalina use 2 disk in Container. Maybe it's the problem. But if i got to Mojave partition, i can access it with "cd System/Library/PrelinkedKernels" or go to "cd System/Library/Extensions" Sent from my iPhone using Tapatalk Edited July 13, 2019 by Andres ZeroCross Link to comment Share on other sites More sharing options...
asstastic Posted July 13, 2019 Share Posted July 13, 2019 I'd like to upgrade to Mojave and test out the Catalina beta but I have not been able to figure out the right combination of settings to get my onboard Intel UHD Graphics 630 working. Everything I have tried so far has resulted in the UHD framebuffer failing to load or a crash at boot and I have not been able to reach the desktop using the UHD Graphics. Any help getting the UHD Graphics working with OpenCore would be greatly appreciated. I've attached my current OpenCore config.plist which is working for booting High Sierra 10.13.6 using the GTX 1060. config.plist Link to comment Share on other sites More sharing options...
Erroruser Posted July 13, 2019 Share Posted July 13, 2019 4 minutes ago, asstastic said: I'd like to upgrade to Mojave and test out the Catalina beta but I have not been able to figure out the right combination of settings to get my onboard Intel UHD Graphics 630 working. Everything I have tried so far has resulted in the UHD framebuffer failing to load or a crash at boot and I have not been able to reach the desktop using the UHD Graphics. Any help getting the UHD Graphics working with OpenCore would be greatly appreciated. I've attached my current OpenCore config.plist which is working for booting High Sierra 10.13.6 using the GTX 1060. config.plist why you not have an gpu settings Link to comment Share on other sites More sharing options...
MattsCreative Posted July 13, 2019 Share Posted July 13, 2019 (edited) please tell me this is a joke logo cause it looks bad like it belongs in an ad for energy or some call center logo here is a phototshop job done of a real company logo with opencore logo its made for one another Edited July 13, 2019 by WarDoc 2 1 Link to comment Share on other sites More sharing options...
Erroruser Posted July 13, 2019 Share Posted July 13, 2019 On 7/11/2019 at 5:58 PM, PMheart said: That can be taken into account WITH LOWEST PRIORITY. lol just like the NVRAM for some of the z390 boards..... right? lol Link to comment Share on other sites More sharing options...
MacPato Posted July 13, 2019 Share Posted July 13, 2019 (edited) Edited July 13, 2019 by MacFriedIntel 1 1 Link to comment Share on other sites More sharing options...
PMheart Posted July 14, 2019 Share Posted July 14, 2019 1 hour ago, errorexists said: lol just like the NVRAM for some of the z390 boards..... right? lol That's totally another story I guess. Currently we are having a tremendous number of new features to implement, which makes us too exhausted to investigate a specific platform. I suppose it would be sensible for users tending to build a new hack to avoid it. As for theming, well, I guess one of the biggest reasons to use OpenCore is to enjoy the fun macOS brings us, instead of themes one might only see for several seconds, which are too fleeting to be enjoyed. Either way, we wish somebody who were willing to and capable to participate in the problem, and finally we would have a solution. We are sorry for lack of time to do it compared to other TODOs that may appear more worthwhile. Best Regards, PMheart 1 1 Link to comment Share on other sites More sharing options...
mhaeuser Posted July 14, 2019 Share Posted July 14, 2019 (edited) @WarDoc Thank you for your feedback. I especially like the harmony of the modern OC logo design with the serif font. /s @MacFriedIntel This one without sarcasm, thank you for your effort, but the logo went through a design process and has been decided on as final, it is not going to be changed any time soon. For your future creations for whatever purpose you should consider (C), as that usage of the Apple logo clearly violates their rights. Personally, we wanted something simple, besides the common "C embedded in the O" concept, a colour palette close to the one of the Mavericks default background bas been used. As for the "Core" inside, unfortunately the name is not established enough for the "Open" part to be implicit. @errorexists If you think the problems you are facing deserve higher priority, you are welcome to submit a fix and it will be reviewed, tested and merged within a day. Meanwhile we will concentrate on issues a lot more people are facing and are a lot easier to solve with the free time we have next to work, education and maybe some free time not spent on maintaining hobby projects. Edited July 14, 2019 by Download-Fritz 8 Link to comment Share on other sites More sharing options...
MacPato Posted July 14, 2019 Share Posted July 14, 2019 3 hours ago, Download-Fritz said: @WarDoc Thank you for your feedback. I especially like the harmony of the modern OC logo design with the serif font. /s @MacFriedIntel This one without sarcasm, thank you for your effort, but the logo went through a design process and has been decided on as final, it is not going to be changed any time soon. For your future creations for whatever purpose you should consider (C), as that usage of the Apple logo clearly violates their rights. Personally, we wanted something simple, besides the common "C embedded in the O" concept, a colour palette close to the one of the Mavericks default background bas been used. As for the "Core" inside, unfortunately the name is not established enough for the "Open" part to be implicit. @errorexists If you think the problems you are facing deserve higher priority, you are welcome to submit a fix and it will be reviewed, tested and merged within a day. Meanwhile we will concentrate on issues a lot more people are facing and are a lot easier to solve with the free time we have next to work, education and maybe some free time not spent on maintaining hobby projects. Should of guessed that there would been an element of inadvertent sarcasm towards the copyright issue (LOL) and i guess a response like that was predictable but as for the design effort, i can see you have taken a minimal approach to the logo. but i can see that AppleLife's community only has a say and an input to anything. @WarDoc was spot on with his comments, to me it doesn't represent a bootloader i feel i should be applying for a credit card or joining to fight climate change. and @errorexists has asked for weeks for someone @vit9696 to look at the Z390 problem and yet again, unless it seems AppleLife has listed it as an issue, it doesn't get looked it. If you plan to let opencore gain ground in a wider community, At least accept there's an issue with these boards and at least try to fix or address the problem. or give some clear indication and instructions on how to fix this in the short term. Link to comment Share on other sites More sharing options...
mhaeuser Posted July 14, 2019 Share Posted July 14, 2019 (edited) @MacFriedIntel I find it hard to judge that a logo does not "represent a bootloader" because usually bootloaders do not have logos, there is very little reference material for associations. Your logo is not something one would find in the wild at all, so I find it hard to have literally any associations with it. I personally dislike it for the hard gradient, but that is nothing that makes sense discussing and it comes down to preference. We liked the smoother gradients of the current logo and the colour palette reflecting the one of the Mavericks default background on the part which happens to have a circular form similiar to the wave of said image. If you dislike our choice, you are free to use different logos for whatever material you happen to provide (like for a theme for a future GUI, if such appears). As for the copyright, that was not sarcastic, we are not looking to violate intellectual property, and neither should you. As you seem to be more reasonable than your friend, I will lay down the Z390 problem once and hope it will be clear enough. First, there already is a workaround, which is the same as for Clover: Use EmuVariable. This has been supported for some time and is what people do to work around the issue for Clover, and has been mentioned and partially discussed throughout the thread. Infact, as it is a good-enough workaround, it had a somewhat high priority. Now, the actual issue why hardware NVRAM is unusable is very unexplored and complex. Basically, UEFI offers a "SetVariable" service to macOS, macOS calls it, but UEFI never returns from the operation, it must get stuck in some kind of deadloop. This is nothing like actual OpenCore issues or other firmware quirks, where a couple of prints provide enough information on what the problem is, this requires an analytic approach on how to find out where the code execution gets stuck. This involves reverse engineering, targeted test cases (replace UEFI modules, write a pre-boot app to simulate OS launch and check effects, etc) and toying with a debug environment via serial, as this is unsed by macOS. Short, it is dramatically more effort to investigate than any other issue we had come across previously. Added to that, an alright workaround is already available and it only affects a small user base. Now you tell me, why should we make it a high priority? Because @errorexists keeps whining about it in this thread and our bugtracker? To a bunch of hobbyists from which work he profits without giving literally anything but complaints back? This is beyond ridiculous, and so is that you try to make a point out of frequent complaints by a single person. Z390 is a simple cost/usage equation. Very high cost, very small impact. I do not see how that can be made any clearer than I have tried to make it above, so except for questions requestion clarification on what I already said, any further complaints are going to be ignored and may be silently reported if we feel like they clutter this thread. If anyone wants to turn that into a "a bug report is being censored" because they're upset, enjoy believing that. AppleLife issues usually get preference because the community is more firm with a proper debugging workflow, end of story. If we get a complete set of information that makes a bug obvious or describes a solution anywhere, it will be looked into with the same effort, but that simply does not happen. Edited July 14, 2019 by Download-Fritz 5 Link to comment Share on other sites More sharing options...
MacPato Posted July 14, 2019 Share Posted July 14, 2019 7 minutes ago, Download-Fritz said: @MacFriedIntel I find it hard to judge that a logo does not "represent a bootloader" because usually bootloaders do not have logos, there is very little reference material for associations. Your logo is not something one would find in the wild at all, so I find it hard to have literally any associations with it. I personally dislike it for the hard gradient, but that is nothing that makes sense discussing and it comes down to preference. We liked the smoother gradients of the current logo and the colour palette reflecting the one of the Mavericks default background on the part which happens to have a circular form similiar to the wave of said image. If you dislike our choice, you are free to use different logos for whatever material you happen to provide (like for a theme for a future GUI, if such appears). As for the copyright, that was not sarcastic, we are not looking to violate intellectual property, and neither should you. As you seem to be more reasonable than your friend, I will lay down the Z390 problem once and hope it will be clear enough. First, there already is a workaround, which is the same as for Clover: Use EmuVariable. This has been supported for some time and is what people do to work around the issue for Clover, and has been mentioned and partially discussed throughout the thread. Infact, as it is a good-enough workaround, it had a somewhat high priority. Now, the actual issue why hardware NVRAM is unusable is very unexplored and complex. Basically, UEFI offers a "SetVariable" service to macOS, macOS calls it, but UEFI never returns from the operation, it must get stuck in some kind of deadloop. This is nothing like actual OpenCore issues or other firmware quirks, where a couple of prints provide enough information on what the problem is, this requires an analytic approach on how to find out where the code execution gets stuck. This involves reverse engineering, targeted test cases (replace UEFI modules, write a pre-boot app to simulate OS launch and check effects, etc) and toying with a debug environment via serial, as this is unsed by macOS. Short, it is dramatically more effort to investigate than any other issue we had come across previously. Added to that, an alright workaround is already available and it only affects a small user base. Now you tell me, why should we make it a high priority? Because @errorexists keeps whining about it in this thread and our bugtracker? To a bunch of hobbyists from which work he profits without giving literally anything but complaints back? This is beyond ridiculous, and so is that you try to make a point out of frequent complaints by a single person. Z390 is a simple cost/usage equation. Very high cost, very small impact. I do not see how that can be made any clearer than I have tried to make it above, so except for questions requestion clarification on what I already said, any further complaints are going to be ignored and may be silently reported if we feel like they clutter this thread. If anyone wants to turn that into a "a bug report is being censored" because they're upset, enjoy believing that. AppleLife issues usually get preference because the community is more firm with a proper debugging workflow, end of story. If we get a complete set of information that makes a bug obvious or describes a solution anywhere, it will be looked into with the same effort, but that simply does not happen. Thank You for the Clarification, It does seem to be an isolated issue with 2 users of Asus Z390 Boards, i had a Similar issue with a MSI Z390 Board and even EmuVariable wasn't successful in my case, i gave up and switched to a working Z370. I'm sure @errorexists will see your post, And the frustration with him is the fact the board he has was a gift from his children, which i think as to why he gets upset with the fact it doesn't work with or without the workaround. checking NVRAM after bootup doesn't indicate its working and yes i think there is some issues with the way the UEFI is getting stuck in a loop as you said. I personally don't see any advantage over the Z370 to upgrade to Z390 as the Z370 along with Z97's are most compatible. I will today make a New EFI for him and get him to post me a log so that we can see for sure what the issue is. if this is something you are willing to look at. Link to comment Share on other sites More sharing options...
MacPato Posted July 14, 2019 Share Posted July 14, 2019 (edited) @Download-Fritz Example of NVRAM.plist is missing from the Tools Directory on build of OC, it says it's there in the manual but doesn't seem to be there. Edited July 14, 2019 by MacFriedIntel Link to comment Share on other sites More sharing options...
justin Posted July 14, 2019 Share Posted July 14, 2019 (edited) 10 minutes ago, MacFriedIntel said: Example of NVRAM.plist is missing from the Tools Directory on build of OC, it says it's there in the manual but doesn't seem to be there. You need to compile OpenCore from latest git commit and you'll find Utilities/LogoutHook/LogoutHook.command, this tool is used to create nvram.plist. Even without third party tools, the Documents is already very clear on the structure: Root {Version, Add} , "Add" is the same structure as config.plist/UEFI/Add/ attached is an example. nvram.plist Edited July 14, 2019 by justin Link to comment Share on other sites More sharing options...
MacPato Posted July 14, 2019 Share Posted July 14, 2019 1 hour ago, justin said: You need to compile OpenCore from latest git commit and you'll find Utilities/LogoutHook/LogoutHook.command, this tool is used to create nvram.plist. Even without third party tools, the Documents is already very clear on the structure: Root {Version, Add} , "Add" is the same structure as config.plist/UEFI/Add/ attached is an example. nvram.plist Okay so might be an idea to add that to the manual. but thanks Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted July 15, 2019 Share Posted July 15, 2019 (edited) @Download-Fritz, I can't build latest OpenCorePkg or AppleSupportpkg with macbuild.tool for each folder., there is line about "Repository https://github.com/acidanthera/OcSupportPkg named OcSupportPkg contains CRLF line endings" But build is ok if i just build with source edksetup.sh build -a X64 -b RELEASE -t XCODE5 -p OpenCorePkg/OpenCorePkg.dsc Edited July 15, 2019 by Andres ZeroCross Link to comment Share on other sites More sharing options...
mhaeuser Posted July 15, 2019 Share Posted July 15, 2019 @Andres ZeroCross One just gotta love VS... fixed 3 1 Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted July 15, 2019 Share Posted July 15, 2019 On 7/12/2019 at 11:35 PM, vit9696 said: Generally that's fine. It should not change unless /S/L/E kexts change. > I reboot My PC and boot to openCore, Do not do that. Please boot straight to UEFI Shell (add it as EFI/BOOT/BOOTx64.efi) then load OpenCore. I have a suspect that EFI file system drivers are faulty, so better not to reboot. On 7/12/2019 at 11:35 PM, vit9696 said: Generally that's fine. It should not change unless /S/L/E kexts change. > I reboot My PC and boot to openCore, Do not do that. Please boot straight to UEFI Shell (add it as EFI/BOOT/BOOTx64.efi) then load OpenCore. I have a suspect that EFI file system drivers are faulty, so better not to reboot. SOLVED : i have checked the PrelinkedKernel date in System/Library/PrelinkedKernel and the date is 3 July 2019. Weird I run kext utility.app and PrelinkedKernel's date is not change,, then i open terminal and run "sudo mount -uw /" and "sudo killall Finder' then i re-Run Kext utility.app. The date of Prelinked kernel is change Now reboot and i can see patch is succesfull,, i am boot with Salado Framebuffer now. 2 Link to comment Share on other sites More sharing options...
hardcorehenry Posted July 16, 2019 Share Posted July 16, 2019 Could someone help me with HPET. I don’t have DSDT in OC/ACPI on my Haswell hackintosh, only SSDT hotpatches . No SSDT-HPET.aml hotpatch can make _STA return 0xf. My original OEM HPET looks like this: Device (HPET) { Name (_HID, EisaId ("PNP0103") /* HPET System Timer */) // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0F) }) Method (_STA, 0, NotSerialized) // _STA: Status { If (LGreaterEqual (OSYS, 0x07D1)) { If (HPAE) { Return (0x0F) } } ElseIf (HPAE) { Return (0x0B) } Return (Zero) } Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings { If (HPAE) { CreateDWordField (BUF0, \_SB.PCI0.LPCB.HPET._Y0F._BAS, HPT0) // _BAS: Base Address If (LEqual (HPAS, One)) { Store (0xFED01000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */ } If (LEqual (HPAS, 0x02)) { Store (0xFED02000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */ } If (LEqual (HPAS, 0x03)) { Store (0xFED03000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */ } } Return (BUF0) /* \_SB_.PCI0.LPCB.HPET.BUF0 */ } } Link to comment Share on other sites More sharing options...
justin Posted July 16, 2019 Share Posted July 16, 2019 1 hour ago, hardcorehenry said: Could someone help me with HPET. I don’t have DSDT in OC/ACPI on my Haswell hackintosh, only SSDT hotpatches . No SSDT-HPET.aml hotpatch can make _STA return 0xf. My original OEM HPET looks like this: Device (HPET) { Name (_HID, EisaId ("PNP0103") /* HPET System Timer */) // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0F) }) Method (_STA, 0, NotSerialized) // _STA: Status { If (LGreaterEqual (OSYS, 0x07D1)) { If (HPAE) { Return (0x0F) } } ElseIf (HPAE) { Return (0x0B) } Return (Zero) } Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings { If (HPAE) { CreateDWordField (BUF0, \_SB.PCI0.LPCB.HPET._Y0F._BAS, HPT0) // _BAS: Base Address If (LEqual (HPAS, One)) { Store (0xFED01000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */ } If (LEqual (HPAS, 0x02)) { Store (0xFED02000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */ } If (LEqual (HPAS, 0x03)) { Store (0xFED03000, HPT0) /* \_SB_.PCI0.LPCB.HPET._CRS.HPT0 */ } } Return (BUF0) /* \_SB_.PCI0.LPCB.HPET.BUF0 */ } } upload your orig DSDT.aml, i can help create a find and replace patch for you to make sure the HPET always return 0xF Link to comment Share on other sites More sharing options...
HmO Posted July 16, 2019 Share Posted July 16, 2019 Device (HPET) { Name (_HID, EisaId ("PNP0103") /* HPET System Timer */) // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0F) }) Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0F) } Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings { Return (BUF0) /* \_SB_.PCI0.LPCB.HPET.BUF0 */ } } Link to comment Share on other sites More sharing options...
hardcorehenry Posted July 16, 2019 Share Posted July 16, 2019 Sorry, wasn't precise. When I put back my patched DSDT everything works, but I have KP in other systems, so removed it. Trying with only hotpatches, my HPET looks like this: // Fix HPET devices DefinitionBlock("", "SSDT", 2, "hack", "HPET", 0) { External(_SB.PCI0.LPCB, DeviceObj) Scope(_SB.PCI0.LPCB) { Device (HPET) { Name (_HID, EisaId ("PNP0103")) // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (BUF0, ResourceTemplate() { IRQNoFlags() { 0, 8, 11, 15 } Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y30) }) Name (_STA, 0x0F) Method (_CRS, 0, NotSerialized) { Return (BUF0) } } } } and it doesn't seems to load. Renaming HPET to XPET, also doesnt help. Attaching my OC.zip Link to comment Share on other sites More sharing options...
justin Posted July 16, 2019 Share Posted July 16, 2019 what do you want? if you only want to have HPET return 0xF, as i've said, upload your untouched DSDT.aml, i can help to make a find/replace patch. 36 minutes ago, hardcorehenry said: but I have KP in other systems what is the "other systems" ? Link to comment Share on other sites More sharing options...
Pavo Posted July 16, 2019 Share Posted July 16, 2019 Why are you messing with HPET in the first place? 1 Link to comment Share on other sites More sharing options...
Recommended Posts