Leaderboard

This project is dedicated to Lucy, my lovely little indoor tiger. IntelLucy is an open source driver for the Intel X500 family of 10 GBit Ethernet controllers. Key Features of the Driver Supports Intel X520, X540, X550 and 82598 Ethernet adapters. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP segmentation offload with IPv4 and IPv6. Support for TCP/IPv4, UDP/IPv4, TCP/IPv6 and UDP/IPv6 checksum offload. Large Receive Offload: TCP/IPv4 packet streams are identified by the NIC and reassembled to large packets for handover to the network stack eliminating the overhead of packet header processing. Supports jumbo frames up to 9000 bytes (strongly recommended for 10 GBit/s operation). Designed to work with High Sierra and above. Supports Wake on LAN tagging. Supports hardware VLAN (untested). Support for Energy Efficient Ethernet (EEE) is planned for future releaes. No need for hardware modifications anymore (used to be required for SmalltreeIntel8259x.kext). Compatible with AppleVTD but also works fine with AppleVTD disabled. The driver is published under GPLv2. Current Status IntelLucy has been successfully tested with Catalina, Monterey, Ventura and Sonoma and is ready for use in production systems starting with version 1.0.0. Thanks to jumbo frame support, performance is much better than com.apple.DriverKit-AppleEthernetIXGBE. VLAN support has been fixed and tested in version 1.0.0 and is fully working now. I can't test Wake on LAN because I don't have an adapter with WoL support. Tested Configurations X520-DA1 with the following media: Passive DAC cable: working 10GBase-SR SFP+ modules: working 1000Base-T SFP modules: working X540-TA1: working (see note below). X540-TA2: both ports working (see note below). Known Issues Manual media selection doesn't work. The link is always established with the highest data rate both link partners support, i.e. 10 Gbit/s if both endpoints support it, 1 Gbit/s if the link partner is a Gigabit device, etc. As DAC cables and fibre optics usually are fixed-speed devices, only RJ-45 ports are affected by this limitation. Try to avoid media with flow control enabled as it might cause repeated connection drops due to transmitter hangs and serious performance issues. For WoL to work you need 4 things: An adapter which supports WoL (only a few X520 adapters support WoL). A mainboard which supports WoL from an add-in card. WoL must be enabled in the UEFI setup. Proper ACPI tables for MacOS to support wakeup. Installation Use OpenCore to inject the driver: Getting the driver A prebuilt binary is available in the download section: https://www.insanelymac.com/forum/files/file/1061-intellucy/ Source code can be found on GitHub: https://github.com/Mieze/IntelLucy Changelog Version 1.0.3 (2024-04-17): Disabled ASPM for the X520 adapters as it is broken and may case erratic behaviour. Enabled ASPM on X540 and X550 provided they report ASPM compliance. Fixed a link status reporting issue for RJ-45 ports (X540 and X550). Removed support for 10 Mbit/s data rate (unsupported on X520 and X540). Resolved a conflict between adaptive interrupt throttling and Receive See Coalescing. Version 1.0.0 (2024-04-07): Fixed relaxed ordering of PCIe transactions. Fixed and tested VLAN support. Version 1.0.0d9 (2024-03-27): Improved transmit performance. Version 1.0.0d6 (2024-03-20): Added support for Intel 82598. Version 1.0.0d5 (2024-03-19): First public release. IntelLucy configuration Parameters explained The Info.plist file contains a section with configuration parameters ("Driver Parameters") which will be explained in the following section: enableTSO4: Enables support for TCP segmentation Offload with IPv4. Using TSO4 the NIC receives large TCP/IPv4 packets from the network stack to be split up into smaller packets to be transmitted of the network. TSO4 is a major performance feature and required to achieve TCP transmission rates near wire speed. enableTSO6: Enables support for TCP segmentation Offload with IPv6. enableWakeOnAddr: Currently unused. enableASPM: Enables Active State Power Management (ASPM) on X540 and X550. rxBufferSize4k: Use 4KB receive data buffers instead of 2KB buffers. rxCoalescing: Enabled the use of Receive Side Coalescing which is the receive side counterpart of TSO4. The NIC identifies TCP/IPv4 packets belonging to a TCP stream, coalesces them into large packets (up to 64KB) and hands them over to the network stack reducing header processing overhead. Enabling rxCoalescing enforces the use of 4KB receive buffers. µsPollTime10G: Under heavy load receive and transmit interrupts are disabled and the NIC is polled periodically for packets waiting to be processed. This feature greatly reduces CPU load while operating at full speed. The polling period is given in µs and used when 10G Bit/s link speed is established. µsPollTime2G: Same as µsPollTime10G but for link speed 2.5 Bit/s (X550 only). µsPollTime5G: Same as µsPollTime10G but for link speed 5 Bit/s (X550 only) µsRxItrTime: Interrupt throttling is important to achieve high data rates while keeping CPU load low. This parameter determines the minimum timespan between two receiver interrupts in µs. Values below 10 enable adaptive throttling. µsTxItrTime: Same as µsRxItrTime but for the receiver interrupt.

1st beta ... no drama ...

( OCLP 1.4.3 nightly still works 🙃 )

macOS Sonoma 14.5 (23F5049f) Full Installer http://swcdn.apple.com/content/downloads/08/26/052-63603-A_72I9KV9QUS/flhemtlnjiql8wqx40cz7i2i5tjfqt84ny/InstallAssistant.pkg

Done all ok

macOS Sonoma 14.4.1 ( 23E224 ) Full Installer https://swcdn.apple.com/content/downloads/04/13/052-77516-A_4P7VY083DT/83qy3989rsnylxagdmim3owwjdtc33zfe4/InstallAssistant.pkg

👍

Z690 Hack update went well

macOS Ventura 13.6.6 (22G630) Full Installer https://swcdn.apple.com/content/downloads/39/23/052-64249-A_9F709WX21B/y8u836xffflrewihfvnacmy3p4v8rm3w57/InstallAssistant.pkg

Amd kernel patches are doing their job as usual

No issues. Everything works.

👍

OCLP (1.4.3) still works 👍

2nd beta ...

No issues here

AMD patches still working

👍

Clover 5158 is out. It was compiled in Sonoma 14.4.1 with gcc13.1 and Python 3.12.1, xcode 15.3

Nobody said the update size. I will

The update was successful. 😎

SBM= Disabled Update ok

Update on Dell Optiplex 790 base Graphics Kepler Upgrade Hardware with a SSD M.2 2TB 980 EVO NVMe on a cady Socket M.2 NGFF SATA SSD This old PC is a really cool

Done

AMD kernel patches are good

I have built the very first kernel. It is fully supported. Patch is included. EDIT: I have used the latest patch and have recreated the kernel. Also included is the BootKernelExtensions.kc file. EDIT2: New version based on Shanee's patch. XNU-14.0.0-AnV_R3.zip

With OC Compiled 1.0.0, its all fine too

@Max.1974 Regarding Clover and security, there are no conceptual blockers. The technical ideas of Clover and OC are not so different and not implementing sound SB support really is just a dev decision. And I son’t think they are going to reconsider. The rest I can only address by a history lesson. In 2013 or so, I started submitting changes to Clover - a bit shoddy at first, but it got better quickly. In 2014, I started RE’ing Apple-proprietary EFI extensions. Some time in 2015 or so, I started proposing integrating some into Clover, starting with the boot hotkeys. I got a response akin “Hack cannot support hotkeys because it’s no Mac” at the time, despite providing RE’d headers and implementations. The same year I started talking to The HermitCrabs Lab, so I decided “well, ok, give it to Ozmosis then”. Contributing to both Clover and Oz, I proposed collaborating more and got meddled up in their beef with Slice, who dropped the same ridiculous comments about Oz then as he does now about OC. There were claims Oz stole a lot of stuff from Clover, but once I got access to the repos much later, I could validate first-hand most rather happened vice-versa. Anyway, Oz kept expanding with my RE results, including the bless support that now makes OC support for macOS installers and such seamless. When Vitaly re-appeared in 2017, we tried to get FV2 working with Clover and were faced with serious technical issues from Clover’s side. Around the same time, Clover v3 got proposed and I - yet again - tried to push for a collaboration. Alas, the project leadership was a mess and nothing ever happened. At the same time yet, HermitCrabs wanted to re-do Ozmosis - basically OC v0. Tired of the technical issues with Clover v2, Vitaly acquired the thing and we started bringing the pieces together. And - yet again - we tried to collaborate, basically suggesting to make this Clover v3. At some point, there were talks that Slice may contribute the GUI to OC. What we got instead were no contributions whatsoever and instead the snarky comments about Oz became snarky comments about OC. So when Clover started leveraging OC libraries in 202x, I - yet again - suggested to collaborate. After all, we know our code best. So I made remarks about stuff like how they used our symbol patcher and I was basically told I’m just here to hate on their efforts. Two weeks later, they hit the very issue I warned them of and applied the fix I told them to ahead of time. So, everyone chiming wisdoms about “but there’s always two parties” and “drop the beef”, sorry that I will not try a fifth(!) time to turn this nonsense into something constructive. I think I got more burnout from Team Clover politics than from all OC work to date.

@D3v1L No, I wouldn't do that, because macOS already has its advantages over Windoof!! You just have to have some time to get to grips with the new Sonoma. That's my personal opinion and as a pensioner I have enough time for that 🙂

Apple Secure Boot is the technology used in Macs to verify the integrity of the operating system at boot: boot loader > kernel > system volume snapshot. If this check fails, macOS won't boot. Apple Secure Boot only works during the boot process, once macOS is running it no longer performs any function. Apple defines 3 Secure Boot modes: Full Security: Only allows to boot the installed operating system or another signed version of macOS in which Apple currently trusts. It also checks the integrity of the installed version. If the check fails, the system offers to reinstall macOS or boot from a different disk. Medium Security: Checks that the installed version of macOS is legitimate but not the integrity of the system. Lets you boot any signed version of macOS in which Apple has ever trusted. No Security: other systems or versions different from those mentioned in the secure options are allowed. There are no requirements on the boot operating system. Apple Secure Boot state on Intel-based Macs can be obtained from NVRAM: nvram 94b73556-2197-4702-82a8-3e1337dafbfb:AppleSecureBootPolicy If the variable is found, it can be one of the following: %02 - Full Security Mode %01 - Medium Security Mode %00 - No Security Mode If the variable is not found, Apple Secure Boot is not supported. SecureBootModel with other value than Disabled gives Medium Security, for Full Security you must use ApECID. SecureBootModel and ApECID: with SecureBootModel=Disabled>> no security (%00) with SecureBootModel=x86legacy or any of the valid values >> medium security (%01) with SecureBootModel= any of the T2 values plus ApECID non zero >> full security (%02). Notice that since OpenCore 0.7.2: x86legacy is designed for machines without T2 chip with Big Sur and Monterey j137 doesn't work on Monterey j137 is the recommended value for macOS 10.13.2 through 10.15.x systems older than macOS 10.13.2 must set SecureBootModel=Disabled users who don't want to have Apple Secure Boot for any reason can set SecureBootModel=Disabled, even in Big Sur and Monterey. In summary, these are muy opinions: I appreciate the interest that the Opencore developers have had in making our Hacks as similar as possible to a real Mac, including Apple Secure Boot. I know that it is impossible for everything to be exactly the same, but they have managed to give OpenCore features that very often make me forget that I am using a Hack and not a real Mac SecureBootModel=Disabled does not appear to lower the Hack's security below a required level, at least for personal PCs. SecureBootModel only acts at boot time to check the legitimacy/integrity of the booting system. Another thing is in multi-user environments (business...) where a malicious user can access the Hack to boot it from a device with manipulated macOS. I don't agree 100% with @Slice. There are Macs without T2 that have Apple Secure Boot medium security, for example iMac19,1 with macOS 10.14 or newer. But I do agree with him that having SecureBootModel enabled or disabled has no/little importance in Hacks. Without forgetting that Clover lacks this property and many thousands of users have used it and are using it to full satisfaction.

Security on Apple computers provided by encryption by T2 chip which we have no. So why SecureBootModel is useless for us.

Since it makes us happy, I can't resist it!! 😊

Done

Done too But OpenCore 1.0.0 and with About This Hack==> boot loader Clover think need correction !

Sonoma 14.4.1 (23E224) Update completed no worries. If you're using OCLP Nightly version, you may as well update that to latest version.

@maly70 Try look here Placa sem fio Intel AX211NGW Wi-Fi 6 M.2: CNVio2, Bluetooth 5.3, adaptador de rede Tri Band 2.4/5/6 GHz para laptop compatível com Windows 10/11 (64bit) Linux Chrome OS disponível apenas com CPU Intel 12+ geração 【Interface NGFF (M.2) CNVio2】Esta placa LAN sem fio AX211 está disponível apenas com 12 gerações de CPU e placa-mãe de protocolo M2 CNVio2.

Thank you guys, we not forget donate to the Ukraine cause, thanks a lot for this brilliant and excellent program. In fact its so amazing, because the traditional way to install Windows has many trouble with disks, especially Nvme, and take off, put again, disconnect GPU, etc... This program is affordable and exclusive to make this task easy and softly Amazing Job ! Really !!

I doubt he will ever give up, he's got that ......'Tie me Kangaroo down Sport'........ attitude being a Man from the Land Down under.

...never give up, never surrender, you have a working ventura system, so just treat sonoma as a challenge yet unanswered, a hobby, or like me, a mini-addiction

14.5 Beta (23F5059e) update went well on Z690 HACK

I released version 1.0.0 of IntelLucy, uploaded a new binary and pushed source code to GitHub. Here is a list of changes: Fixed relaxed ordering of PCIe transactions as it may cause strange behaviour in certain situations. Fixed and tested VLAN support. Version 1.0.0 is recommended for production systems as it has passed all tests and is fully working. All users of previous version should upgrade to version 1.0.0. Have fun❣️

Hi my friends, here it's all ok with native Broadcom Pcie Wireless and Bluetooth device, Model: BCM94360CD. No need use AirportBrcmFixup or BluetoothFixup kexts, just BrcmFirmwareData and BrcmPatchRAM3. Not using OCLP - OTA update fine. AirDrop et all working native. 😉

If the Open Core change log remains as planned, the next release of Open Core will be version 1.0.0. There's nothing significant about this version numbering, as it is simply the numerical progression from version 0.9.9. As with recent OCLP versions after OCLP 0.9.6, there does not appear to me to be any compelling reason to upgrade to the latest Open Core binaries; however, I will be updating the OC EFI attached to Post #1 only to have an OC EFI for OC 1.0.0.

@eng_redaesm Developers link, get OpenCore-Patcher.app (GUI). https://github.com/dortania/OpenCore-Legacy-Patcher/actions/runs/8326849351 @eSaF has posted the script by @LAbyOne , it works very well but I am not comfortable with a shared app on InsanelyMac whose code is not accessible. It's just a personal opinion.

I confirm you are one commit behind 520c922 " Fix last " ... once the app is opened it shows 1.5 But the last commit is as I wrote before bbc8902 " Add non-Metal support for macOS 14.4 " ... once the app is opened it shows 1.3

Secound test OK on test Branch Workflow is fix Pull Request