Jump to content

[Discussion] Intel i225-V on macOS Monterey


Irish_Man
380 posts in this topic

Recommended Posts

Here's the solution for the i225-v v2 problem, especially on Gigabyte-boards

 

VT-d must be enabled on the system. On some boards it works without dropping the original DMAR table, but unfortunately not on most Z490 Gigabyte boards.

 

After that it goes like this:

 

 

1. Remove all i225-v related device properties and boot-args from config.plist.


2. Set DHCP and automatic configuration of link speed in network settings.


3. Copy eeupdate64.efi and I225MOD from the attached I225-Vmod.zip to an USB stick formatted with (MBR) FAT32.


4. Start the EFI-shell via OpenCore and change to the directory of the USB stick (should be FS0, so change with (probably) fs0:).


5. Start the eeupdate64e.efi in gui mode: eeupdate64e /gui and select the I225-V.


6. Select Raw EEPROM - Extended.

 

7. Press F3 and enter a name for your original EEPROM dump file and confirm with OK. The EEPROM dump will be saved on the USB stick.

 

8. Press F4 to load the I225MOD file from the USB stick (enter I225MOD, press ENTER and confirm loading the file) - you should not overwrite the original MAC address when importing (you will be asked).


9. Press ESC to exit and confirm saving.


10. Start macOS (cold boot - completely disconnect computer from power and then press power button for several seconds) and check if it works - you may need to remove and add again the network adapter in preferences.


 

 

 

I225-Vmod.zip

Edited by badbrain
  • Like 6
  • Thanks 3
Link to comment
Share on other sites

Guest 5T33Z0
25 minutes ago, Shaneee said:

@5T33Z0 literally just above Irish_Man's post... 🤦‍♂️

 

Ah, ok. I ignored his content so it was hidden. I remember now, why I did do that.

 

So this fix basically requires flashing a different EEPROM. If it fails, the Ethernet Controller is basically toast after that. I just want to point that out as a disclaimer since nobody has stated that yet.

Edited by 5T33Z0
Link to comment
Share on other sites

This statement is simply wrong and can only come from someone who is not familiar with the subject.

In step no. 7 you create the dump of the eeprom register before, which you can write back at any time. This is nothing else than the ethtool method, where you can change the individual offset values.

 

This has nothing to do with a firmwareflash. And if? Many hackintoshers flash e.g. their Thunderbolt cards with a modded firmware or their board with a modded BIOS, which has nothing to do with the process described here. 

So it's not for people who don't know or understand what you're doing. Those who don't dare or are afraid to do so can continue to enjoy their toast under macOS. 😉

Edited by badbrain
  • Like 2
Link to comment
Share on other sites

@miliuco

 

He means the VT-d related settings. With this method no further changes (no device properties or boot-args) in the config.plist are necessary.

The I225-V runs without problems with the dext driver com.apple.DriverKit-AppleEthernetE1000.dext and is identified correctly.

 

Also the Hackintool recognizes the device as Ethernet controller I225-V.

If you have problems, you can also use the com.apple.driver.AppleIntelI210Ethernet.kext by setting the boot-arg e1000=0 to see if this works better for you.

 

The I225-V will run with both drivers after the mod.

 

Edited by badbrain
  • Like 2
Link to comment
Share on other sites

1 hour ago, miliuco said:

@Irish_Man

What minor .plist adjustements? Are they related to i225-V?

The only change i’ve made was  the settings of DisableIOMapper. Changed it from YES to NO. In Bios I’ve had  VT-d already enabled. I’ve never disabled it. 

  • Like 1
Link to comment
Share on other sites

@badbrain I tried both the  com.apple.DriverKit-AppleEthernetE1000 and the com.apple.driver.Applelnte||210Ethernet for this onboard I225-V ethernet controller.

Your suggested procedure to finally get this NIC working has been successfully applied to 2 of my GA-Z490 Vision G mobos, the only disadvantage for me, in my particular environment at least is that, with "Wake for network access" enabled, the hack goes into a perpetual "sleep loop" ie. it sleeps as required and in accordance with the timer settings, however it wakes again 15 seconds after it has actually gone to sleep. Disabling "Wake for Network access" cures this problem.

I do however require this "Wake for network access" functionality, which has always been reliably provided by a DGE-526T PCIe add-on network controller, therefore I have no choice to continue using a NIC that actually works as intended. In any case thanks for your endeavours in at least getting the I225-V NIC working somehow with limited functionality.

 

Greetings Henties

 

 

Screenshot without e1000=0.png

Screenshot with e1000=0.png

  • Like 1
Link to comment
Share on other sites

Guest 5T33Z0

I can confirm that badbrain's fix is working for my Z490 Vision G's I225 Controller.

 

- VT-d was enabled already

- DisableIOMapper was unselected already

- Original DMAR was dropped and replaced already by a modified one with removed memory regions to get my 3rd party network card working. (But the I225 works without dropping DMAR as well for me)

- No more DeviceProperties nor boot-args are required for Big Sur and Monterey.

- I guess for Catalina you still need the Kernel Patch to change the Device ID of the Controller. But haven't tested that yet.

 

Great, so now I can remove the 3rd party card.

Edited by 5T33Z0
Link to comment
Share on other sites

@Henties

 

I cannot confirm the behavior you describe and the limited functionality associated with it.
Sleep works properly for me even with the option enabled. It must have something to do with your system or configuration (OpenCore, BIOS).

 

However, I am using a Vision D and not a G.

 

Link to comment
Share on other sites

@badbrain Thanks for your feedback, will therefore use one of my hacks to try getting to the bottom of this non functioning "Wake for network access" phenomena.

Perhaps somebody else with a Vision G mono can throw some light on this issue. 

 

Greetings Henties

 

Without a SSDT.DMAR.aml and the corresponding DMAC.aml, my I255-V NIC works well on my GA-Z490 Vision G , however I am still getting the "sleep loop" described in an earlier posting of mine.

 

@5T33Z0 would appreciate if you test this on your system, which is also GA-Z490 Vision G based, and let me know the outcome.

 

Greetings Henties

Edited by Henties
Feedback
Link to comment
Share on other sites

Guest 5T33Z0

@Henties Can you enter this in terminal please to find out the actual wake reason:

 

 pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"

 

BTW, Ethernet is still working after 12.4 Beta (21F5048e) update.

 

Edited by 5T33Z0
Link to comment
Share on other sites

@5T33Z0 @badbrainThe sleep boot problem can be tied to the way the OSI networking stack for the I255-V NIC is incorrectly implemented. 

Any traffic (packet) on the network wakes my hack and not only magic packets intended only for this machine.

This manifests itself only under macOS, Monterey and Big Sur but not Windows and or Linux. These operating systems

sleep properly and also wake correctly when magic packets intended for them on this machine arrive.

To prove this I configured a USB network adapter to be the default NIC for macOS with the I255-V as the secondary network device, with the sleep

loop persisting. When I now pull the ethernet cable from the I255-V, the sleep loop vanishes and the hack sleeps as intended.

I can therefore only conclude that regular network traffic is the cause why macOS enters a sleep loop mode when the I225-V is actually physically

connected to my network infrastructure.

Will therefore have to revert back to disabling the onboard I225-V and using a DGE-526T instead because that is working correctly and indeed provides

the functionality required.

 

Greetings Henties 

 

 

 

 

 

 

Link to comment
Share on other sites

Guest 5T33Z0

@Henties My system woke after sending it to sleep after a minute or so. After I disabled PowerNap and unselected "Ruhezustand nach Netzwerkzugriff beenden",  the system remained sleeping. If this issues is related to these "magic packets" you are refering to, my guess is that it needs to be fixed in macOS. Alternatively, you could try injecting some ASPM settings for the Controller via DeviceProperties. https://github.com/5T33Z0/OC-Little-Translated/tree/main/04_Fixing_Sleep_and_Wake_Issues/Setting_ASPM_Operating_Mode

Link to comment
Share on other sites

On 4/5/2022 at 8:14 PM, badbrain said:

Here's the solution for the i225-v v2 problem, especially on Gigabyte-boards

 

VT-d must be enabled on the system. On some boards it works without dropping the original DMAR table, but unfortunately not on most Z490 Gigabyte boards.

 

After that it goes like this:

 

 

1. Remove all i225-v related device properties and boot-args from config.plist.


2. Set DHCP and automatic configuration of link speed in network settings.


3. Copy eeupdate64.efi and I225MOD from the attached I225-Vmod.zip to an USB stick formatted with (MBR) FAT32.


4. Start the EFI-shell via OpenCore and change to the directory of the USB stick (should be FS0, so change with (probably) fs0:).


5. Start the eeupdate64e.efi in gui mode: eeupdate64e /gui and select the I225-V.


6. Select Raw EEPROM - Extended.

 

7. Press F3 and enter a name for your original EEPROM dump file and confirm with OK. The EEPROM dump will be saved on the USB stick.

 

8. Press F4 to load the I225MOD file from the USB stick (enter I225MOD, press ENTER and confirm loading the file) - you should not overwrite the original MAC address when importing (you will be asked).


9. Press ESC to exit and confirm saving.


10. Start macOS (cold boot - completely disconnect computer from power and then press power button for several seconds) and check if it works - you may need to remove and add again the network adapter in preferences.


 

 

I225-Vmod.zip 936.29 kB · 4 downloads

Can I apply this fix also for my i225-v on the Asus ROG B550-I motherboard?
The ethernet interface works most of the time but sometimes I have to set the speed to manual and back to automatic to re-activate the interface after a new boot.

Link to comment
Share on other sites

@5T33Z0 I have actually given up on this one for now. 

The problem originates from my router supplied by my ISP.

When only the router is connected to my Vision G I255-V onboard NIC, I cannot use the "Wake for network access" functionality at all,

the machine continuously enters into a sleep/wake loop. The only way that I can use the machine is when the "Wake for network access"

function is disabled. This phenomenon manifests itself on both of my Vision G hacks.

When I isolate the router from my network both of the Vision G hacks, with the I225-V NIC sleep without problems.

Looks like I need to motivate my ISP to supply me with a later model internet router, as it appears that the ip implementation of 

the one in service needs updating.

I have now reverted back to a DGE-560T on both hacks. These D-Link branded gigabit NICS are quite capable to comfortably endure

what the router happens to "throw" at them.

The problem is that I am now sacrificing a PCIe slot which would come in quite handy for something else, had it actually been available.

 

Greetings Henties

Edited by Henties
Link to comment
Share on other sites

1 hour ago, zztop12 said:

Can I apply this fix also for my i225-v on the Asus ROG B550-I motherboard?
The ethernet interface works most of the time but sometimes I have to set the speed to manual and back to automatic to re-activate the interface after a new boot.

Apply this fix and then report success or no.

Link to comment
Share on other sites

Guest 5T33Z0

SInce I flashed this EEPROM I couldn't get the I225 get to work in Catalina any longer with the required DeviceProperty and Kernel Patch.

 

But it doesn't bother me much since a) I moved to Big Sur as my primary OS, b) I have a third party network card which I can use if I have to and c) it's more important to me to have the I225 forward compatible rather than backward compatible.

Link to comment
Share on other sites

×
×
  • Create New...