Jump to content

Dr. Hurt

Members
  • Content Count

    1,583
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    Dr. Hurt reacted to vandroiy2012 in OpenCore Discussion   
    OK. 
    So OpenCore boots latest beta macOS 10.15 without any problem!
    Kext injection is working without any interference. 
     
    Thanks @vit9696
  2. Like
    Dr. Hurt got a reaction from PippoX0 in OpenCore Discussion   
    Any plans for this to run on bios using UEFI emulation? Like the clover legacy boot mechanism.
  3. Like
    Dr. Hurt reacted to Slice in Clover General discussion   
    May be ebuild.sh changed and I didn't notice the change in 
    !ifndef NO_GRUB_DRIVERS INF Clover/FileSystems/GrubFS/src/EXFAT.inf #INF Clover/FileSystems/GrubFS/src/NTFS.inf !endif Before this I always compiled with the key NO_GRUB_DRIVERS.
    I will check next release.
     
  4. Like
    Dr. Hurt reacted to vit9696 in OpenCore Discussion   
    Are you in your senses? What is wrong with copying EmuVariableEfi from e.g. MdeModulePkg or Clover (if you cannot compile) and just putting it to drivers? Sure, we do not support this configuration as we want a cleaner solution, but why would not it work in the first place?
     
    @dgsga, am I right that Clover devs modded EmuVariable in a way that it does not load unless explicitly controlled with a protocol you added?
  5. Like
    Dr. Hurt reacted to vit9696 in OpenCore Development   
    Hi apianti,
     
    Let me try to address your questions in order.
     
    I am not particularly sure whether this refers to memory configuration available in SMBIOS or not, as presently memory performance is not affected anyhow regardless of what is present in SMBIOS. Firmware is responsible for memory training, and thus the operating system can do almost nothing but use what is given. Neither the amount of memory slots, nor their order, not even their channels, nothing of that really affects the operating system. This is pretty much cosmetics except useable memory size. You might think differently potentially due to some legacy, yet I will need code proofs in case you think it is important.
     
    Perhaps, I misunderstood you, and what you meant under memory configuration performance was rather building performance and the quality of the tables provided. This is not a big concern either, as OpenCore simply provides what is created by the firmware with little to no modifications. So far it seems to work most reliably on all modern computers (2008 or so) and virtual machines. Additionally it provides good results in "About my Mac".
     
    The only "real" issue, that we are aware of, are very rare motherboards, which contain incorrect information in their SMBIOS tables. We do not have such boards, but believe this may be addressed with a dedicated MemorySMBIOS section in PlatformInfo, where one could describe his memory (as I mentioned on applelife), yet the issue has low priority, and we do not have plans to work on it in the considerable future. If this worries you, you can try to write a design document and create an issue in the bugtracker. After we come to some consensus, I suppose you could contribute a useful feature to OC.
     
    There is, as boot strap application is not meant to be the only way to start OpenCore. OpenCore should generally be bootable from Drivers#### NVRAM variables (currently not fully implemented), from shell, or from firmware. Bootstrap is a way to ensure that target firmware definitely does see the image as defined by UEFI spec, it may be removed if otherwise not required.
     
    The modular approach behind OC is primarily that OcSupportPkg libraries can be used to build whatever necessary in whatever configuration, not particularly for building a bootloader, but implementing other entirely unrelated projects. On the contrary, the front end is defined by the spec (named instruction manual), and while it is extensible, a spec change is needed to bring any new functionality. For this reason the written spec in human language translates 1:1 into config.plist, which then transparently translates 1:1 into OcConfigurationLib. We believe that conformance and unification are necessary here to actually ensure predictability and reliability for the end user, who always knows how the target system behaves, and what is actually happening. Indeed, this made configuration monolithic, but we consider it a benefit not a downside. We have some internal plans to expose the configuration for read and potentially modification for drivers (like UI or external providers) as a part of some protocol, but we do not have plans to let drivers add anything bypassing the spec.
     
    OpenCore is and will remain an open source project. There are quite a number of opensources licenses (see this page), and BSD 3-clause license is one of them. I think you might confuse GPL or something alike with an open source license. One of the key benefits of BSD 3 clause license contrary to GPL (and several others) is to ensure that the code does not "disown" your patents and does not prohibit code usage in closed source projects. This is very important, as you probably noticed, that OpenCore has a lot of code that has nothing to do to macOS or bootloaders in general, it is just generic UEFI code we wrote. For these very reasons, primarily to be able to contribute our code in similar or reworked form to upstream, such as TianoCore EDK II, we do not use licenses prohibiting commercial use. This is the same with all projects hosted at Acidanthera unless specified otherwise.
     
    Cheers,
    Vit
  6. Like
    Dr. Hurt reacted to vit9696 in OpenCore Discussion   
    It has run just fine on legacy bios since the beginning…
    Presently it is tested with DuetPkg clover fork.
  7. Like
    Dr. Hurt got a reaction from witampanstwa_ in [How To] Share files between OS X 10.7+ and Android over WiFi without SAMBA   
    **I'm not sure if this topic goes here so mods feel free to move it to the appropriate section.
     
    Ever since updating from 10.6.8 to 10.8.2, I've had a nasty problem with file sharing between my Android (ES File Explorer) and Mac OS.
    I could no longer authenticate into my Mac using SMB to access different "volumes". The only way was to add the entire volume I need as a public folder which in my case is totally unacceptable.
    I needed password protected access to the volumes.
     
     
    How I got around it?
    Easy. Using SFTP:
     
    I went into System Preferences -> Sharing -> marked "allow remote login".
     
    Next on my android tablet, I opened es file explorer, selected SFTP, typed my IP, user name and password and BOOM. I have full access to all mounted volumes again. And I believe its even faster than SMB.
     
    What happend between Snow Leopard and Lion/Mountain Lion?
    Well, I believe that Apple ran into a licensing issue with SAMBA so they had to trim down support for SMB and replace it with AFP. Only AFP can authenticate and access password protected volumes.
    This problem appears to be plaguing OS X Lion/ML users everywhere. Most people suggest reinstalling the old SAMBA which can be a pain in the @ss. I believe this solution is much more elegant.
     
    I hope this comes in handy to someone like me who depended on SAMBA to share files between android and Mac OS.
  8. Like
    Dr. Hurt reacted to Andres ZeroCross in Clover General discussion   
    Hi @Slice can you make AudioDXE.efi play sound without nvram set,, like bootchimedxe. So AudioDxe.efi will automatic select audio output and sound at high volume if no nvram set yet in "Startup Sound Output".
  9. Thanks
    Dr. Hurt got a reaction from Emanuele-1998 in VirtualSMC — SMC Emulator   
    -273C is 0 Kelvins (absolute zero). I think this happens when no battery temperature is reported (battery hardware doesn’t support reporting temperature).
     
    As for sudden shutdowns, that could mean your battery is going bad. It’s reporting incorrect capacity. Try to calibrate it by charging to 100% then discharging to power off. Repeat a couple of times.
  10. Like
    Dr. Hurt got a reaction from Badruzeus in Clover General discussion   
    The boot chime works perfectly using AudioDXE.efi and BootChimeDXE.efi in the drivers64 folder. Those (and only those) two drivers are enough to get the chime going when the macOS boot entry is selected in Clover.
     
    The only annoyance for me is that Clover takes 3 extra seconds to start. Hopefully that will be slightly optimized in the future.
     
    PS. My laptop does have UEFI but its disabled. I'm using legacy boot.
     
  11. Like
    Dr. Hurt reacted to vit9696 in Clover Change Explanations   
    Rev 4846
     
    Fixes random kernel panics in macOS 10.14 upon boot when kext injection is used and keepsyms=1 boot argument is not provided. Now this should work just as normal like in 10.13 and lower.
  12. Like
    Dr. Hurt reacted to Sherlocks in Clover General discussion   
    @vit9696
    thank you for r4846 commit.
    this is very great fix. i had problem unknown panic on sandy bridge laptop until this commit.
    there is no more instant reboot issue
    thanks
     
  13. Confused
    Dr. Hurt got a reaction from Badruzeus in Clover General discussion   
    Sorry if this has been asked before, but how do I get the boot chime with Clover legacy?
     
    Which files do I need and where do I put them? Also, any changes needed in config? 
    I'm using embedded theme.
     
    Edit: Got it to work. A users' guide would still be useful though.
  14. Like
    Dr. Hurt reacted to chris1111 in Clover General discussion   
    Another Mac chime 
     
     
    Mac Chime.zip
  15. Like
    Dr. Hurt reacted to Pavo in Lilu — kext and process patcher   
    Ok looks like Lilu 1.3.0 has fixed my issues with VirtualSMC instant rebooting with non-verbose booting. Thanks again @vit9696 for helping me debug that issue.
  16. Like
    Dr. Hurt reacted to SavageAUS in VirtualSMC — SMC Emulator   
    Mine was happening just after you see the apple logo the first time. Bam instant reboot.


    Sent from my iPhone using Tapatalk
  17. Like
    Dr. Hurt got a reaction from Matgen84 in VirtualSMC — SMC Emulator   
    I sometimes get reboot too as soon as the boot progress bar appears.
    Booting in verbose works. Alternatively, keepsyms=1 also works.
    I'm not sure what's causing it but glad I'm not the only one.
     
    This doesn't always happen. Can't seem to find a way to reproduce it.
  18. Like
    Dr. Hurt got a reaction from Andrey1970 in Clover General discussion   
    Make sure SetIntelBacklight is also set to true. This seems like a rather annoying new requirement.
  19. Thanks
    Dr. Hurt reacted to Sherlocks in Clover General discussion   
    you are not set SetIntelBacklight option
    17:027  0:000  120  |  33  2D  54  4C  45  31  00  4E
    17:027  0:000  Intel GFX injection not set
    17:028  0:000  stringlength = 150
    17:028  0:000  CurrentMode: Width=1366 Height=768
    17:028  0:000  Beginning FSInjection
    17:028  0:000   - ERROR: gFSInjectProtocolGuid not found!
    17:028  0:000  Use origin smbios table type 1 guid.
    17:028  0:000  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other
     
    there was no log for intel backlight
     
    try
        <key>Devices</key>
        <dict>
            <key>SetIntelBacklight</key>
            <true/>
            <key>SetIntelMaxBacklight</key>
            <true/>
        </dict>
  20. Thanks
    Dr. Hurt reacted to Andres ZeroCross in VirtualSMC — SMC Emulator   
    I don't know,, my notebook now can sleep in charge mode,, and i can wake it with USB device (mouse), before of it it will instant wake with ACPIBatteryManager.kext and i Need to remove PRW method from GLAN, EHC1, EHC2 and XHC to avoid instant wake when notebook in charge mode. Now,, with VirtualSMC.kext, i don't need to remove _PRW method from those device. System can sleep well in Charge and uncharge condition, and system can wake from USB device (_PRW method is still there).

    Thanks @vit9696
  21. Like
    Dr. Hurt got a reaction from ellaosx in VirtualSMC — SMC Emulator   
    No, just Clover and the RC script.
     
    But again, I think Lilu could be used to make a better virtual NVRAM implementation.
  22. Like
    Dr. Hurt reacted to chriz74 in Decompiled original Apple DSDTs   
    here are the dumps: 
     
    https://applelife.ru/threads/darwindumper-dampy-nastojaschix-macov.39174/
  23. Like
    Dr. Hurt reacted to amoxitine in Atheros wireless driver OS X 10.11/12 for unsupported cards   
    Hi Doc,
     
    I'm using a combo of the patched Airport kext, with Lilu and the ath9k/Inject/Fixup kexts installed in Clover / Other and then using the -ath9485 boot param in config. No DSDT patches in relation to that AFAIK, but where I've had help from other people over the last month, a patch might have snuck in there but probably unlikely.
     
    Would really like to crank the speed up so I'm curious as to why you're getting better transfer speeds and I'm not, perhaps it's where I am using the arth9k stuff that is actually causing the speed issues? Might try disabling that to see if that does indeed work.
  24. Like
    Dr. Hurt reacted to amoxitine in Atheros wireless driver OS X 10.11/12 for unsupported cards   
    I have a Dell DW1703 which has the AR9485 and oddly whilst in general I only see a max Tx rate of 11Mbps when connected to all other routers I've tried so far, when I connect my home router (which is an old BT Home Hub 3.0) it's actually showing a Tx Rate of up to 72Mbps and comparatively the transfer speeds are faster (hitting 20-30Mbps from a 60-70Mbps connection) rather than the 1-5Mbps I would get when connected to other WiFi routers.
     
    Not sure why or what my hub is doing differently to get these increased speeds, but I thought I'd mention that it would appear the 11Mbps Tx 'limit' on the AR9485 can be broken somehow. 
  25. Like
    Dr. Hurt got a reaction from Badruzeus in Clover General discussion   
    Since Clover can change PCI config registers, I’d like to suggest integrating the functionality of FakePCIID_XHCIMux.kext
     
    This’ll replace the need for complicated DSDT patches or additional kexts. And I believe this is a patch used by a big enough number of users to warrant its addition to Clover.
     
     
×