obus Posted June 14, 2019 Share Posted June 14, 2019 Can't load my USBPortlimitKext if I inject it trough OC: If I install it into Library/Extensions it works fine: Tried booth wit and without ExecutablePath in config. What am I doing wrong? Link to comment Share on other sites More sharing options...
glasgood Posted June 14, 2019 Share Posted June 14, 2019 9 minutes ago, obus said: Can't load my USBPortlimitKext if I inject it trough OC: If I install it into Library/Extensions it works fine: Tried booth wit and without ExecutablePath in config. What am I doing wrong? Not sure, tbh I'm still figuring this out. I just finally got my Aorus Pro Z390 running with OC. But what I did notice was that when I used an SMBIOS for iMac 1.1 , I had all my ports injected from SSDT-UIAC plus an extra 6 ports that where not defined inside SSDT-UIAC ! But when I changed SMBIOS to iMac 19,1 I have exact amount of ports injected as per my SSDT-UIAC. As I am using USBInjectAll.kext, I have I never install anything in Library/Extension. I use OC kext folder. Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 (edited) 1 hour ago, obus said: Can't load my USBPortlimitKext if I inject it trough OC: If I install it into Library/Extensions it works fine: Tried booth wit and without ExecutablePath in config What am I doing wrong? Problems solved with help from my saver @PMheart the kext is now injected correctly from OC. After changing bundles in kext and removing ExecutablePath in OC config. Edited June 14, 2019 by obus Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 (edited) 3 hours ago, glasgood said: Not sure, tbh I'm still figuring this out. I just finally got my Aorus Pro Z390 running with OC. But what I did notice was that when I used an SMBIOS for iMac 1.1 , I had all my ports injected from SSDT-UIAC plus an extra 6 ports that where not defined inside SSDT-UIAC ! But when I changed SMBIOS to iMac 19,1 I have exact amount of ports injected as per my SSDT-UIAC. As I am using USBInjectAll.kext, I have I never install anything in Library/Extension. I use OC kext folder. My kext is working fine with iMacPro1,1 SMBIOS after changing bundles in kext and removing ExcutablePath in OC config. Here is my kext. Just take the port info from your SSDT-UIAC and copy to the kext and then activate portlimitpatch in OC XhciPortLimit. --> YES C422-XHCI.kext.zip Edited June 14, 2019 by obus New kext Link to comment Share on other sites More sharing options...
D-an-W Posted June 14, 2019 Share Posted June 14, 2019 1 hour ago, obus said: Problems solved with help from my saver @PMheart the kext is now injected correctly from OC. After changing bundles in kext and removing ExecutablePath in OC config. Can you please screenshot how it looks after the change as I think I have the same problem? Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 15 minutes ago, D-an-W said: Can you please screenshot how it looks after the change as I think I have the same problem? You mean like this? Link to comment Share on other sites More sharing options...
D-an-W Posted June 14, 2019 Share Posted June 14, 2019 Sorry, I meant the change you made in the OC Config.plist Link to comment Share on other sites More sharing options...
obus Posted June 14, 2019 Share Posted June 14, 2019 (edited) 9 minutes ago, D-an-W said: Sorry, I meant the change you made in the OC Config.plist If you have 16 ports ore more you need to inject XhciPortLimit -- YES. I f you have 15 ports or less you don't need it as I learnt from my friend @PMheart Edited June 14, 2019 by obus 1 Link to comment Share on other sites More sharing options...
D-an-W Posted June 15, 2019 Share Posted June 15, 2019 (edited) Hi folks, Would anyone perhaps know what might have changed between OpenCore v0.0.3 REL-003-2019-06-07 and the latest commits to give me the error in the screenshot below? I can boot normally on the earlier version... I did see this so reverted it and compiled locally but still get the same error. Edited June 15, 2019 by D-an-W Link to comment Share on other sites More sharing options...
glasgood Posted June 15, 2019 Share Posted June 15, 2019 (edited) 7 hours ago, obus said: My kext is working fine with iMacPro1,1 SMBIOS after changing bundles in kext and removing ExcutablePath in OC config. Here is my kext. Just take the port info from your SSDT-UIAC and copy to the kext and then activate portlimitpatch in OC XhciPortLimit. --> YES C422-XHCI.kext.zip @obus Thanks, will try kext out. 4 hours ago, D-an-W said: Hi folks, Would anyone perhaps know what might have changed between OpenCore v0.0.3 REL-003-2019-06-07 and the latest commits to give me the error in the screenshot below? I can boot normally on the earlier version... I did see this so reverted it and compiled locally but still get the same error. Hi did you provide the ExecutablePath ? Edited June 15, 2019 by glasgood Link to comment Share on other sites More sharing options...
glasgood Posted June 15, 2019 Share Posted June 15, 2019 @obus Hi, I used Hackintool to create USBPorts.kext as your kext has specifics for SMBIOS iMacPro1,1 and I'm using iMac 19,1. I noticed differences, in my kext created with Hackintool has IONameMatch as XHC and it contains power properties for sleep and wake. I noticed that my XHCI to XHC renames are being correctly implemented. Link to comment Share on other sites More sharing options...
uglyJoe Posted June 15, 2019 Share Posted June 15, 2019 5 hours ago, D-an-W said: Hi folks, Would anyone perhaps know what might have changed between OpenCore v0.0.3 REL-003-2019-06-07 and the latest commits to give me the error in the screenshot below? I can boot normally on the earlier version... I did see this so reverted it and compiled locally but still get the same error. https://github.com/acidanthera/OpenCorePkg/commit/16528b2d6558ec12a0311c4671ce096984b7c6ec Add UsePicker=true to Misc/Boot to solve ... Link to comment Share on other sites More sharing options...
mhaeuser Posted June 15, 2019 Share Posted June 15, 2019 @uglyJoe unrelated @D-an-W I might have made a typo in one of the last commits... at this point once more the reminder that master is NOT stable and may contain untested code at any point 1 1 Link to comment Share on other sites More sharing options...
uglyJoe Posted June 15, 2019 Share Posted June 15, 2019 (edited) @Download-Fritz May be it should unrelated but it isn't. I got the same error if I do some tests with UsePicker=false... maybe a bug? Btw: How to use this new option? If I load OpenCore from shell with UsePicker=false, I got 'Halting on critical error' Edited June 15, 2019 by uglyJoe Link to comment Share on other sites More sharing options...
mhaeuser Posted June 15, 2019 Share Posted June 15, 2019 @uglyJoe interesting... I wonder whether that uncovers a hidden bug, yeah. Link to comment Share on other sites More sharing options...
uglyJoe Posted June 15, 2019 Share Posted June 15, 2019 Different tryings with UsePicker=false Link to comment Share on other sites More sharing options...
D-an-W Posted June 15, 2019 Share Posted June 15, 2019 Many thanks folks, will test it and report back. Link to comment Share on other sites More sharing options...
glasgood Posted June 15, 2019 Share Posted June 15, 2019 On 6/5/2019 at 5:29 AM, asstastic said: I've been following along with CoreBoot development for a while but was completely overwhelmed by the documentation the first time I looked into setting it up. Decided to give it a go with the beta release of Catalina. Turns out it wasn't as difficult as it looked initially and I've been able to get boot, graphics, audio and USB injection working. I could still use some help resolving an nvram issue. Regardless of the EFI drivers used, I still get an AMI safe boot "F1" warning after reboot. I get the following results with various EFI driver combinations: AptioMemoryFix only: System boots. Does not power off on shutdown or restart EmuVariableRuntimeDxe only: System boots. On verbose ('-v') boot console log shows a black screen after "End RandomSeed" until Apple boot logo. Shutdown/Restart functional EmuVariableRuntimeDxe and AptioMemoryFix: System boots with Apple console log visible and shutdown/restart functional no NVRAM efi drivers: Boot hangs at "End RandomSeed" Also a warning: VariableRuntimeDxe is not the same as EmuVariableRuntimeDxe. I compiled VariableRuntimeDxe.efi from the master branch of UDK thinking newer must be better. The module crashed on load, corrupting the motherboard memory and required shorting the motherboard CMOS pins before it would post again. Hi, Where do I source EmuVariableRuntimeDxe ? can you hyperlink source please. Link to comment Share on other sites More sharing options...
D-an-W Posted June 15, 2019 Share Posted June 15, 2019 45 minutes ago, Download-Fritz said: @uglyJoe interesting... I wonder whether that uncovers a hidden bug, yeah. @uglyJoe fixed it here too, thanks! @Download-Fritz thanks, I understand things might not be stable...I just like testing it on USB 1 Link to comment Share on other sites More sharing options...
blackosx Posted June 15, 2019 Share Posted June 15, 2019 (edited) On 6/13/2019 at 8:02 AM, vandroiy2012 said: Your motherboard does not need any patches at all. On 6/13/2019 at 8:15 AM, vit9696 said: @vandroiy2012 is perfectly right that people should not be modding ACPI when they have no good grasp of the spec. If we had time to explain how to write dsl code, sure, you may not have made mistakes, but we cannot help everyone. I had time to test this morning and using OC without my patched DSDT works great. And even better, I had a sleep issue which I always knew was ACPI related but could not find the time/be arsed to fix, and now sleep works which proves my DSDT was borked! Thanks guys Edited June 15, 2019 by blackosx Added ‘patched’ 4 1 Link to comment Share on other sites More sharing options...
glasgood Posted June 15, 2019 Share Posted June 15, 2019 On 5/1/2019 at 9:23 AM, dgsga said: @vit9696 Recent Z390 Aptio V motherboards don’t support native NVRAM with AptioFixPkg. With Clover the solution is to use EmuVariableUefi.efi. Is there any way to emulate NVRAM with OpenCore? Hi @dgsga What is the alternative to EmuVariableUefi.efi for Z390, for working NVRAM ? Link to comment Share on other sites More sharing options...
blackosx Posted June 16, 2019 Share Posted June 16, 2019 I don't think this would qualify for adding to bugtracker so am posting it here. I've spotted in the Configuration.pdf that some 'Default value' settings for booleans read NO rather than false. This is the case for the following: 7.4 Debug Properties ---------------------- 1. DisableWatchDog 10.2 Properties ---------------------- 1. ConnectDrivers 10.3 Protocols Properties ---------------------- 2. ConsoleControl 10.4 Quirks Properties ---------------------- 2. IgnoreInvalidFlexRatio 3. IgnoreTextInGraphics 4. ProvideConsoleGop 6 Link to comment Share on other sites More sharing options...
PMheart Posted June 16, 2019 Share Posted June 16, 2019 2 hours ago, blackosx said: I don't think this would qualify for adding to bugtracker so am posting it here. I've spotted in the Configuration.pdf that some 'Default value' settings for booleans read NO rather than false. This is the case for the following: 7.4 Debug Properties ---------------------- 1. DisableWatchDog 10.2 Properties ---------------------- 1. ConnectDrivers 10.3 Protocols Properties ---------------------- 2. ConsoleControl 10.4 Quirks Properties ---------------------- 2. IgnoreInvalidFlexRatio 3. IgnoreTextInGraphics 4. ProvideConsoleGop Fixed at https://github.com/acidanthera/OpenCorePkg/commit/7045dbaaa978a7045dcf2561514304b14bd76d2a, thanks! 3 2 Link to comment Share on other sites More sharing options...
MacPato Posted June 16, 2019 Share Posted June 16, 2019 Maybe update the sample config and docs to show the changes with boolean, as the latest build doesn't have the changes made to the files. Link to comment Share on other sites More sharing options...
FredWst Posted June 17, 2019 Share Posted June 17, 2019 Hi, I'm using vault and signature. I would like to report users using that to be carefull with naming files. For example DSDT.AML is not correct it must be DSDT.aml -> or just like me you'll spend time to understand why OS doesn't boot ... OpenCore.log said 01:031 00:000 OCS: Aborting ACPI\DSDT.aml file access not present in vault There's many way to improve that. I think isn't priority but if users using more and more this feature, it could be a major issue for them. Fred Link to comment Share on other sites More sharing options...
Recommended Posts