Dietmar

@reboot12 Yes, this is a really nice board, that you can dump whole Bios without a lot of cables!

@reboot12 yessa I found this Bit and change via ru.efi in Uefi Variable Setup Offset 132F 1 ==> 0 and store via CTRL w . Now a lot more I can see in Bios Dietmar

@reboot12 0x26737 Suppress If {0A 82} 0x26739 QuestionId: 0x8 equals value 0x1 {12 06 08 00 01 00} 0x2673F Subtitle: Statement.Prompt: , Flags: 0x0 {02 87 02 00 00 00 00} 0x26746 End {29 02} 0x26748 One Of: Setup Item Hidden, VarStoreInfo (VarOffset/VarName): 0x132F, VarStore: 0x1, QuestionId: 0x8, Size: 1, Min: 0x0, Max 0x1, Step: 0x0 {05 91 72 18 73 18 08 00 01 00 2F 13 10 10 00 01 00} 0x26759 One Of Option: Enabled, Value (8 bit): 0x1 (default) {09 07 03 00 30 00 01} 0x26760 One Of Option: Disabled, Value (8 bit): 0x0 {09 07 04 00 00 00 00} 0x26767 End One Of {29 02}

@reboot12 It is this extracted Dietmar https://www.upload.ee/files/19141261/mioo.txt.html

@reboot12 I get only a 16MB Bios flash, but the Hidden I found in Setup. Do you have an ifr extractor for XP? I think only version 0.5 or below will work Dietmar https://www.upload.ee/files/19141235/AmericanMegatrendsInc.-5.13.rom.html

@reboot12 I can use ru.efi and dmpstore in shell. dmpstore I cant save, but look at all the blocks. Nothing more with sense just now Dietmar

@reboot12 For me not: HII is blocked Dietmar

@reboot12 Yes, I have the same 7F everywhere Dietmar

@reboot12 Thanks, but I dont want to write something at unknown place in Bios. I need a tool, for to SEE the variables from my Bios Dietmar

@reboot12 Because I cant SEE any name of variables and my Bios seems to be a little bit different from your, a line like asw.efi 0xb52 0x0 may be very dangerous because it writes 0x0 at some unknown place, which may be not Bios Lock. I disabled Bios Lock in Bios itself, but still gets message about HII not possible, means data are locked Dietmar

@reboot12 sceefi64.efi /o /s settings.txt writes only about HII not possible. Can I use ru.efi or dmpstore Dietmar

@reboot12 sceefi64 /o /s bla.txt WARNING: HII data does not have setup questions information

@reboot12 amisetupwriter 0x1330 0x0 NVRam variable "Setup" read, data size 0x1330, atrtribute 0x3, Offset value 0x1330 is greater than variable size 0x1330, aborting

@reboot12 I am not as good as you in working with *.efi files. I make Fat32 USB stick and put there in D:\EFI\Boot the modGRUBShell.efi renamed to bootx64.efi . And in D:\ I put AmiSetupWriter.efi This I mean, that you need to write Tutorial with ALL needed files *.efi that you use Dietmar

@reboot12 Can you make a short nice Tutorial, step by step, what needs to be done to Disable ME in Bios, here for the AIMB-786. It is not a dangerous Bios hack, just to enable hidden settings in Bios. And make a pdf of this Tutorial, put all needed programs into it for download Dietmar

@reboot12 I force this i219 driver for to enable 100MB. The shown speed is only the speed, that the NIC can do on 4 pair lan cable. Because on most compis this driver wants to fall back to 10MB. It is not the fault of this driver, but of the bad Bios on most boards how to "speak" with their router. And yes, about this "power on" when shut down: It is a side effect, because I tried to disable really all in ME, ULP etc. in the driver itself. On most boards this works and there is no Bios switch needed Dietmar

@reboot12 I make a try to overcome ME in the driver i219.sys direct. For this, I check all the register values with ME and without. Then, after compi starts, I write to all the registers back as if there was no ME. This works, I tested. BUT: After starting network traffic, suddently again ME writes all its values back to the registers and so ME stops the lan driver, I can see this with Windbg in Real Time. Crazy. This makes a very unstable situation. So, the makers of the win7 and win10 i219 driver must have a way, to tell Me: shut up. This way I dont have, may be ME looks, if this is a certified driver. Anyway this test was very interesting for me what is going on. So, I also use your methode, to stop ME in Bios. Interesting, if this can be done on any compi Dietmar ME / Host Handoff Summary from the XP SP3 i219 Windbg ====================================================== 1) Core register block I test for to the put ME out and give control back to me ----------------------------------------------------------------------------------------------- MMIO register offsets that I touch in the driver when trying to move NIC ownership away from the ME path and back to the host driver, called "me": 0x5820 0x5B50 0x5B54 0x5B64 These four offsets appeare in the relevant handoff-related functions: I219MeTransitionToHost I219DisableUlpPhy I219LowPowerExitFixup I219PostLinkHostHandoff I219RuntimeMeReassert So, the "ME out / host takes over" register block was 0x5820 / 0x5B50 / 0x5B54 / 0x5B64 2) Registers I additionally watch as truth indicators ---------------------------------------------------------------------------- 0x0008 = STATUS register 0x5820 = MANC / management-related state And also I watch those TX/RX-related registers to see the downstream effects: 0x0400 0x0404 0x3810 0x3818 0x3828 0x2810 0x2818 So - For actively trying to force ME out, the core registers were: 0x5820 / 0x5B50 / 0x5B54 / 0x5B64 - For detecting whether ME had taken control again, the most important indicators were: 0x0008 and 0x5820 3) Values that shows i219 driver, me, has control" ----------------------------------------------------------------- STATUS @ 0x0008 = 00080600 MANC @ 0x5820 = 00e20000 This pair means: The host driver, me, has the NIC in the intended host-controlled state 4) Values that show, ME has taken control again --------------------------------------------------------------------- STATUS @ 0x0008 = 00080643 MANC @ 0x5820 = 00e30000 5) proof ------------------------------------------------- All logs showed the same sequence: Step 1: Driver forces host state STATUS = 00080600 MANC = 00e20000 Step 2: Later, the values flip back to STATUS = 00080643 MANC = 00e30000 Step 3: After that, unstable link behavior appears, such as LinkState -> UP 100Mb FD then later LinkState -> DOWN 10Mb HD or repeated "LAN cable disconnected / reconnected" behavior So, with only via driver i219 hacking, ME is not gone in XP SP3, like Terminator "I’ll be back.." Dietmar

@reboot12 I just set up environment for XP bit 64, also with WDK 7600 . Here are the for XP64 compiled files with *.inf for the i219.sys driver. I make one version with the original source V1 i219 driver (moreDev driver) and another one, with better(?) compatibility for XP64. Both each fre and chk version good luck Dietmar https://www.upload.ee/files/19139298/XPP64.zip.html

@reboot12 I wonder, if this bit in MMIO status 0x40000000 is now set all the time, when ME is disabled. This you can see at very first part, when you run windbg with any of my drivers. There is a real chance for us to understand, how ME forbids this driver for i219 to write via TX Dietmar

@reboot12 Oh Waaaooohhh, I just come home for to see your crazy nice news!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I only get with ME this crazy driver for to read but not to send anything. I wonder, how the people with Linux managed this or do they only use the i219 driver, handed over by Intel? Just now I will try, I think that I have all needed files. And I notice another thing: This industrial board AIMB-786 is a very nice board. It has much more possibilities than nearly ANY new board. For example: Its Bios version 5 is also very nice, because it connects very good to any router (in german it is called "verhandeln"), much better than any other boards that I have. I compile about 100 different drivers. Now I have the problem, which one is best of all. The P0 version has no IRQ. This driver is very stable, but has ping always 15 ms, while other drivers with IRQ have smaller ping in network. I need to look, how to compile for 64 Bit, nice work Dietmar

@reboot12 PCI Command 0406 is stable integrated. i219W25_DIAG: PCI_CMD[init] slot=2031622 before=0006 after=0406 (want=0406 MEM+ BusMaster+ DisINTx+) RX works. Now I build a new driver, which produces a lot of traffic TX from itself Dietmar

@reboot12 Oh Waaoooh Dietmar

@reboot12 This is very nice information. It means, that you can enable and disable DMA on the AIMB-786 as you wish. And even it comes from a crazy starting point, this is possibe. AIMB-786 + i219-LM unter XP has now only one problem from now: TX-Consume The i219 chip gets and receives perfekt, but does not "eat" any TX-Descriptor. Already today big advantage! RX is solved. TX-Submit is solved. Only TX-Consume not Dietmar

@reboot12 Now I have all installed on the exact same board AIMB-786, same Bios V5 as you. I use as cooler the nice Dynatron DB128015BU-E. First I thought board is dead, but it awakes after CLEAR CMOS few times. And I have exact the same symptoms: Not any of my i219 drivers sénds or gets a single package, no Ping no DHCP. I go back to the basics: I compare the Bios of the Asus z390 WS Pro with the same i219-LM Dev_15BB with the AIMB-786 board. In the Intel GbE region there are differences, 44 Byte different. But because I dont want to hack the Bios just now, (may be not easy, when length of definition for Dev_15BB are different(!!!) ) I compare the setup routine for the i219. And I notice, that there are already differences very early, even before the first network activity begins. I want to trace and compare all relevant early registers on both boards via Windbg. In the MMIO status is the bit 0x40000000, that is set early but never changed on any of the for the i219 working boards. On the AIMB this bit is never set. But this bit is only the result of a lot as BIOS/NVM setup, ME/firmware state, PHY/ULP/SMBus state etc.. and never asked for this bit on the working boards?! So I try to bring the AIMB-786 into the same register state as the ASUS WS Z390 Pro, step by step. The MMIO status may show the result Dietmar

@reboot12 I make a new driver version i219P0. This driver does not use any IRQ/INT, because it may be, that they are blocked from the Bios of the AIMB-786. https://www.upload.ee/files/19134054/i219P0.zip.html And here is the KD block for it good luck Dietmar sxd ud bc * sxe av sxe gp sxe ud !sym quiet .reload /f i219.sys r $t0=0 r $t1=50 bu /1 i219!DriverEntry ".echo ====DRV_ENTRY====; gc" bu /1 i219!I219MiniportInitialize "r $t4=poi(esp+4); r $t5=poi($t4+0xDC); .echo ====INIT====; .printf \"a=%p regs=%p\n\", $t4,$t5; gc" bu i219!I219MiniportISR ".echo ====UNEXPECTED_ISR_HIT (POLL-ONLY SHOULD NOT USE ISR)====; r; gc" bu /1 i219!I219TxRxStart "r $t4=poi(esp+4); r $t5=poi($t4+0xDC); .echo ====TXRXSTART_SNAP====; .printf \"regs=%p\n\",$t5; dd $t5+0x0008 L1; dd $t5+0x00C0 L1; dd $t5+0x00D0 L1; dd $t5+0x00D8 L1; dd $t5+0x2810 L1; dd $t5+0x2818 L1; dd $t5+0x3810 L1; dd $t5+0x3818 L1; .printf \"TxS=%u TxC=%u Rx=%u\n\", poi(i219!g_TxSubmits), poi(i219!g_TxCompletes), poi(i219!g_RxFrames); gc" bu i219!I219MiniportCheckForHang "r $t0=$t0+1; .if($t0==$t1){r $t0=0; r $t4=poi(esp+4); r $t5=poi($t4+0xDC); .echo ====POLL_SNAP====; dd $t5+0x0008 L1; dd $t5+0x00C0 L1; dd $t5+0x00D0 L1; dd $t5+0x00D8 L1; dd $t5+0x2810 L1; dd $t5+0x2818 L1; dd $t5+0x3810 L1; dd $t5+0x3818 L1; .printf \"TxS=%u TxC=%u Rx=%u\n\", poi(i219!g_TxSubmits), poi(i219!g_TxCompletes), poi(i219!g_RxFrames)}; gc" bu i219!I219MiniportSendPackets "r $t4=poi(esp+4); r $t5=poi($t4+0xDC); .echo ====SEND====; dd $t5+0x3810 L1; dd $t5+0x3818 L1; .printf \"TxS=%u TxC=%u\n\", poi(i219!g_TxSubmits), poi(i219!g_TxCompletes); gc" bu i219!I219TxReclaim "r $t4=poi(esp+4); r $t5=poi($t4+0xDC); .echo ====TXRECLAIM====; dd $t5+0x3810 L1; dd $t5+0x3818 L1; .printf \"TxS=%u TxC=%u\n\", poi(i219!g_TxSubmits), poi(i219!g_TxCompletes); gc" bu i219!I219RxPoll "r $t4=poi(esp+4); r $t5=poi($t4+0xDC); .echo ====RXPOLL====; dd $t5+0x2810 L1; dd $t5+0x2818 L1; .printf \"Rx=%u\n\", poi(i219!g_RxFrames); gc"