STLVNUB Posted December 30, 2019 Share Posted December 30, 2019 Heres a modified build script, you can use GCC5 if you want, but that errors for some reason Just edit script TOOLCHAIN=GCC5 OR TOOLCHAIN=XCODE5 Also creates a shortcut so all you need to do is type ocb ( OpenCore Builder ) to compile. ndk-macbuild.tool.zip enjoy 1 1 Link to comment Share on other sites More sharing options...
mhaeuser Posted December 30, 2019 Share Posted December 30, 2019 (edited) On 12/30/2019 at 10:07 AM, Mike Ranger said: I think those are very useful features..... in my opinion it should be merged what you do. Because I several people pinged me privately about this, I want to quickly clarify why none of these are going to be merged. - ACPI/SMBIOS: While that hasn't always been applied properly for time and resource reasons, but OpenCore is definitely aimed to be deterministic and be formally verifiable. For example, we want to be able to assert "SMBIOS and ACPI data have been patched when macOS boots" (assuming there are no errors). Now, if we also want to assert "SMBIOS and ACPI data have not been patched when Windows boots", we may run into consistency issues. For example take we boot a system for which SMBIOS and ACPI are patched, the booter returns to OpenCore, and then a system is booted for which such shall not be patched - we cannot easily roll those changes back. There are two approaches to resolve this: Make it unconditional -or- do not allow error-exits of loaded images. We opted for former for multiple reasons, among of them that the whole reason ACPI exists is to abstract for *any* OS (which works in practice, at least as far as we are aware, at least with _OSI) and things like Boot Camp tools support in Windows. Also, we do not see any reason why anyone would insist on booting anything but macOS from OpenCore, you may just as well use the firmware boot menu (Clover has caused Windows boot issues as well several times in the past). For many design reasons, OpenCore just ensures a consistent environment instead of supporting a specific OS boot whereever possible. - W hotkey: We believe that even the X hotkey is bad design, but it was added as part of Apple UEFI consistency. This is not the case for W, there simply is no good point in having it at all. - non-verbose APFS: Using apfs.efi is terrible practice and nobody will ever be supported in any way using it. - duplicated entires: You can rename entries with .contentDetails just fine, there simply is no point in having auto-scan *and* custom entires describe the same thing. It's a pointless complication of the control flow and adds complexity to the semantics ("adds an entry *except* when it already exists, where it overwrites"), especially latter we try to avoid at all cost (e.g. "Add" *never* replaces anywhere else). - boot entry with arrow keys: Well, this is discussible, but I simply see no point? Numbers are one key each, arrow keys is arbitrarily many (depending on entry count). - last booted entry: The only reasons I have ever heard in favour of this is updates, for which nobody has reported whether it even is an issue - both macOS and Windows *are* aware they can use BootNext to have be booted on the next startup, so they might actually. Other than that, it wears the SPI flash, requires a new config option and yet again complicates the flow. - hiding tools/recovery by default: OC's boot menu is very small already having a text nature, there yet again simply is no reason to do this. If there are more than a dozen entries, I would call the setup busted. Unused recovery environments can be deleted, some tools might better be off started by UEFI Shell, etc. - fixed Apple logo: I do not know of any present issues and there is no description of how this had been fixed, so nothing to really do here. If you want to submit a bugreport and a fix proposal for this, that'd be good. @n.d.k I'd be glad if you could make sure your fork is easily recognised as such from both boot menu and log, like appending a suffix ("OpenCore-ndk"?) and I'm thinking we actually want that as part of a license extension, as we only want to support release binaries from our GitHub page (not even own compilations, except proper bug reports of course). Other than that, while we do not agree with your changes, the whole point of OSS is a level of freedom, so we wish you the best of luck with adapting this to suit your needs! EDIT: arrow keys were implemented to support bugged laptop hotkeys in the future. Hiding Recovery *might* be considered as, and I didn't realise this when writing this post, Apple hides it in most situations as well Edited January 14, 2020 by Download-Fritz 2 Link to comment Share on other sites More sharing options...
n.d.k Posted December 30, 2019 Author Share Posted December 30, 2019 @Download-Fritz Thanks for the post, It would clarified the reason this whole customized OpenCore thing come into existence. One more thing I want to clarify again as i did in the post#1, these changes and my forks are personal, that's the reason i only share the source. The changes I made to OpenCore are working perfectly for me. And I am not gonna try argue or explain why I made those changes, people can think for themself and not to be forced to think. 6 Link to comment Share on other sites More sharing options...
darthsian Posted January 4, 2020 Share Posted January 4, 2020 (edited) Hi n.d.k, thanks for your work. I have some issues with your customized OpenCore. - If i select macOS boot drive in Startup Disk preference panel, macOS won't boot with error "OCB: LoadImage failed - Not Found. Halting on critical error." - If i select Windows boot drive in Startup Disk preference panel i get message "You can't change the startup disk to the selected disk. The bless tool was unable to set the current boot disk.". - When i use some Tool from Boot Picker (e.g. Shell) so after i quit this tool it won't go back to Boot Picker but i get this error "OC: Tool Tools\<null string> cannot be found! Halting on critical error". All this works on the original OpenCore release without problem. Edited January 4, 2020 by darthsian 1 Link to comment Share on other sites More sharing options...
n.d.k Posted January 5, 2020 Author Share Posted January 5, 2020 13 hours ago, darthsian said: Hi n.d.k, thanks for your work. I have some issues with your customized OpenCore. - If i select macOS boot drive in Startup Disk preference panel, macOS won't boot with error "OCB: LoadImage failed - Not Found. Halting on critical error." - If i select Windows boot drive in Startup Disk preference panel i get message "You can't change the startup disk to the selected disk. The bless tool was unable to set the current boot disk.". - When i use some Tool from Boot Picker (e.g. Shell) so after i quit this tool it won't go back to Boot Picker but i get this error "OC: Tool Tools\<null string> cannot be found! Halting on critical error". All this works on the original OpenCore release without problem. Thanks for the feedback! - The tool problem was fixed with latest commit. - About Startup Disk, it's better to leave it alone since this fork implemented the auto default to last booted entry (only Windows or macOS) and stay there until user choose another entry from picker menu. If you need to switch to another Bootloader/EFI partition that reside in another disk, it need to be done in Bios. 1 Link to comment Share on other sites More sharing options...
matgeo Posted January 11, 2020 Share Posted January 11, 2020 On 1/5/2020 at 2:23 AM, n.d.k said: - About Startup Disk, it's better to leave it alone since this fork implemented the auto default to last booted entry (only Windows or macOS) and stay there until user choose another entry from picker menu. If you need to switch to another Bootloader/EFI partition that reside in another disk, it need to be done in Bios. With latest commits I can no longer select a boot entry with arrow keys or any key at all. Link to comment Share on other sites More sharing options...
n.d.k Posted January 11, 2020 Author Share Posted January 11, 2020 2 hours ago, matgeo said: With latest commits I can no longer select a boot entry with arrow keys or any key at all. OC recently made some changes to keyboard function which related to how it handle the keyboard input, this fork was just simply mirrored the new changes. Although, the changes was tested and worked fine on my machines without any help from keyboard driver at the time the commit changes was pushed to this fork, I won't rule out any potential incompatibility issue with the new codes on some machines. Here are some steps that can help to isolate the problem. - OpenCorePkg & OcSupportPkg are updated from n-d-k repo. - Recompile and test, continue if problem still exists. - Recompile Orignal OC repo and test, if problem still exists then the changes has some compatibility issues, if not then we know the problem only exist in this fork. It's help to know if anyone else does/doesn't have problem using the current changes. Link to comment Share on other sites More sharing options...
Ellybz Posted January 11, 2020 Share Posted January 11, 2020 (edited) 28 minutes ago, n.d.k said: OC recently made some changes to keyboard function which related to how it handle the keyboard input, this fork was just simply mirrored the new changes. Although, the changes was tested and worked fine on my machines without any help from keyboard driver at the time the commit changes was pushed to this fork, I won't rule out any potential incompatibility issue with the new codes on some machines. Here are some steps that can help to isolate the problem. - OpenCorePkg & OcSupportPkg are updated from n-d-k repo. - Recompile and test, continue if problem still exists. - Recompile Orignal OC repo and test, if problem still exists then the changes has some compatibility issues, if not then we know the problem only exist in this fork. It's help to know if anyone else does/doesn't have problem using the current changes. I have the same issues reported by @matgeo on X299. There's also a brief error message before the picker shows @ AllowSetDefault, regardless of its state. (No/Yes) Edited January 11, 2020 by Ellybz Link to comment Share on other sites More sharing options...
n.d.k Posted January 11, 2020 Author Share Posted January 11, 2020 49 minutes ago, Ellybz said: I have the same issues reported by @matgeo on X299. There's also a brief error message before the picker shows @ AllowSetDefault, regardless of its state. (No/Yes) It would help if you can run the DEBUG version and set Misc->Debug->Target to 67 and post the log. I'll see what i can find where the culprit is. and Also perform the steps above to isolate where the problem originated from. Thanks! Link to comment Share on other sites More sharing options...
Ellybz Posted January 11, 2020 Share Posted January 11, 2020 (edited) Here's the log requested . I also compiled & checked the latest original released version. The previous message "No Schema for AllowSetDefault at index 1" disappeared, but I cannot select a boot entry either. ( No response from arrow keys or numeric input ); I will have to investigate further. I rolled back to your previous released version in the mean time. opencore-2020-01-11.txt Edit: After a bit of investigation, it appears that Non AppleKeyboards are useless in selecting options in the picker. ( functions are regained after Apple finish booting ). I even tried with different drivers for the keyboard from OC support Pkg ( I did not need any previously ). Results are the same. Switching to an Apple Keyboard resolved this issue. Only if a driver ( UsbKbDxe.efi ) is present - Edit 2 : After recompiling the previous message @ AllowSetDefault disappeared. Edited January 12, 2020 by Ellybz 1 Link to comment Share on other sites More sharing options...
texem Posted January 12, 2020 Share Posted January 12, 2020 (edited) just compiled the original release of today and the bootpicker keyboard selection stopped working as well. Magic Keyboard via Bluetooth (works from BIOS on) and connected via cable is not working. Latest compile of 9.Jan works, restored via TimeMachine. Whats wrong ? Edited January 12, 2020 by texem 1 Link to comment Share on other sites More sharing options...
n.d.k Posted January 12, 2020 Author Share Posted January 12, 2020 With recent removing legacy key handling mechanism from OC https://github.com/acidanthera/OcSupportPkg/commit/3d9048294ec06e920d1e7967ce5819855c21cc80 it may have broken some keyboard's compatibility. Both of my bluetooth magic keyboard and wireless usb logitech keyboard are working fine without any driver. I will need someone with keyboard problem to test, i can't seem to find any keyboard that doesn't work. Link to comment Share on other sites More sharing options...
Ellybz Posted January 12, 2020 Share Posted January 12, 2020 (edited) @texem @matgeo @n.d.k Solved: Changed UEFI / Input / KeySupport to true ( No driver needed ) Edited January 12, 2020 by Ellybz 1 Link to comment Share on other sites More sharing options...
n.d.k Posted January 12, 2020 Author Share Posted January 12, 2020 3 minutes ago, Ellybz said: @texem @matgeo @n.d.k Solved: Changed UEFI / Input / KeySupport to true ( No driver needed ) Great find, save me some headache...haha.. Thanks! Link to comment Share on other sites More sharing options...
texem Posted January 12, 2020 Share Posted January 12, 2020 mmhhh .. unfortunately not here. The keyboard is dead. Must be something else missing. Link to comment Share on other sites More sharing options...
Ellybz Posted January 12, 2020 Share Posted January 12, 2020 (edited) 13 minutes ago, texem said: mmhhh .. unfortunately not here. The keyboard is dead. Must be something else missing. KeySupportMode needs to be filled. If you have a keyboard driver installed , it will conflict with the keySupport quirk. Edited January 12, 2020 by Ellybz 1 1 Link to comment Share on other sites More sharing options...
texem Posted January 12, 2020 Share Posted January 12, 2020 6 minutes ago, Ellybz said: KeySupportMode needs to be filled. If you have a keyboard driver installed , it will conflict with the keySupport quirk. Works !! Link to comment Share on other sites More sharing options...
n.d.k Posted January 12, 2020 Author Share Posted January 12, 2020 Just a head up for those using NvmExpressDxe.efi, this driver was recently added as part of OC build, it will show a verbose on screen when loading it, use the build script from this fork to compile one instead. 1 Link to comment Share on other sites More sharing options...
btwise Posted January 13, 2020 Share Posted January 13, 2020 "No Schema for AllowSetDefault at index 1"，With the newly compiled version of fork, this is a real problem! Link to comment Share on other sites More sharing options...
n.d.k Posted January 13, 2020 Author Share Posted January 13, 2020 1 hour ago, btwise said: "No Schema for AllowSetDefault at index 1"，With the newly compiled version of fork, this is a real problem! real problem?...hmm Did you do a git pull on OpenCorePkg itself? git pull ./ndk-macbuild.tool 2 Link to comment Share on other sites More sharing options...
Hackintosh Tech Posted January 15, 2020 Share Posted January 15, 2020 Sorry i'm with @Download-Fritz on this one. most of the changes to the custom version of OC are a little pointless and I'm more inclined to support a well-known source. The apple logo issue you mentioned isn't actually a problem, we have found on our server that the restrictions to oversized logos is something related to the way certain UEFI Boards handle GOP and each board and setup requires certain adjustments to the config, some require console mode's set others are left blank, most people can fix the issue of boot resolution with just simply reading the documented PDF guide by the developers of Open core and further to the PDF, https://khronokernel-2.gitbook.io/opencore-vanilla-desktop-guide/ this is a good source for fixes also. Link to comment Share on other sites More sharing options...
Ellybz Posted January 15, 2020 Share Posted January 15, 2020 (edited) I understand the point of developers. But I, the user, still prefer the customizations of this version. Having the options to hide any entries I'd like & in the specific order I choose them to appear ( also making all entries appear just by pressing space bar ) is huge plus. See exemple below. So many other options that I also prefer from the standard release, but these are my favorites. Can't do that with standard release. Edited January 15, 2020 by Ellybz Link to comment Share on other sites More sharing options...
n.d.k Posted January 15, 2020 Author Share Posted January 15, 2020 Here's another pointess change for somebody. 2 2 Link to comment Share on other sites More sharing options...
Hackintosh Tech Posted January 15, 2020 Share Posted January 15, 2020 1 minute ago, n.d.k said: Here's another pointess change for somebody. looks like MS-DOS 1 Link to comment Share on other sites More sharing options...
n.d.k Posted January 15, 2020 Author Share Posted January 15, 2020 1 minute ago, MacPato™ said: looks like MS-DOS What does the original look like? Link to comment Share on other sites More sharing options...
Recommended Posts