VOGONS


Reply 660 of 759, by jamesfmackenzie

User metadata
Rank Newbie
Rank
Newbie

Since no one is selling boards (Unless im wrong, would love a link), It might be worth it to add a dISAppointment shared project on PCBWay/JLCPCB and/or electromaker for ease of purchase for anyone attempting who's not familiar with ordering pcbs from fabs. I doubt they would have the components for assembly, but would make it easier for pcb acquisition.

This would certainly help a newbie like me! 😂

Reply 661 of 759, by Duffman

User metadata
Rank Oldbie
Rank
Oldbie
dartfrog wrote on 2025-04-18, 04:37:

I'm currently waiting on a new response from my friend and Fintek about the previously talked about PCIe/ISA chip F85526. The design might be finalized as it's "possible" to buy F85526 and F85526D from china apparently. Friend has yet to hear back from Fintek or distributors from china though. (This chip has apparently been "around" since 2014 but the design has never been finalized and has never been for sale until recently (past few months))

I'd never heard of the F85526 until now, I wouldn't have thought a PCIe-to-ISA bridge was even possible.

I hope something useful can be made of it.

MB: ASRock B550 Steel Legend
CPU: Ryzen 9 5950X
RAM: Corsair 64GB Kit (4x16GB) DDR4 Veng LPX C18 4000MHz
SSDs: 2x Crucial MX500 1TB SATA + 1x Samsung 980 (non-pro) 1TB NVMe SSD
OSs: Win 11 Pro (NVMe) + WinXP Pro SP3 (SATA)
GPU: RTX2070 (11) GT730 (XP)

Reply 662 of 759, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
dartfrog wrote on 2025-04-18, 04:37:

On a whim I checked out my wife's Gigabyte z390 Aorus motherboard which has a LGA1151 socket (intel coffee lake), PCH Z390 and ITE8688 (sio). Apparently the ITE8688 does have LDRQ# and connects to PCH z390. Though this is not exposed on the TPM header, the rest of the TPM header seems all there to support the dISAppointment. I'll have to build a dISAppointment to test it, but everything on the surface seems fine. I think this would be the most recent intel board that would have it? Unless i'm missing something here. https://www.slideshare.net/slideshow/z390-des … 10pdf/259237641

From the datasheet you linked, it seems the net meant for so-called "LDRQ0#" actually connects to the PCH's GPP_A7/PIRQA#/GSPI0_CS1# (per 300 series datasheet).

I wonder what SuperIO would be using that pin for, as the PCH no longer provides any LDRQ# signal nor have any 8237 controller in it...

Reply 663 of 759, by robertmo3

User metadata
Rank Oldbie
Rank
Oldbie
rasteri wrote on 2023-03-19, 14:49:

Disappointed that your modern PC doesn't have ISA?
Well - you've been lied to. Your motherboard does have an ISA bus, but it's locked away inside the chipset. And we can help it escape

what about VLB? are there any boards that could have vlb added? what about socket 5 motherboards with no vlb connector?

Reply 664 of 759, by Tiido

User metadata
Rank l33t
Rank
l33t

VLB is a very big ask since it is mostly 386/486 CPU bus with a few extra signals. That is the main reason it disappeared when Pentium arrived.

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 665 of 759, by dartfrog

User metadata
Rank Newbie
Rank
Newbie
jamesfmackenzie wrote on 2025-04-18, 05:25:

This would certainly help a newbie like me! 😂

Indeed! When I order my pcbs and they come back like they should, I can convert the order to said project page.

Duffman wrote on 2025-04-18, 06:52:

I'd never heard of the F85526 until now, I wouldn't have thought a PCIe-to-ISA bridge was even possible.

I hope something useful can be made of it.

Yeah it's an interesting chip if it provides a true full PCIe to ISA bridge like it claims. I am dubious, but hopeful it is. Couple of us talked about it in the thread previously. There are also FPGA cores that claim to do varying levels of PCIe to ISA bridge too. From my research on the topic, it's totally possible to have a complete PCIe to ISA bridge with DMA but i'm skeptical that the chip does it. The bridge chip would need to translate ISA DMA requests into equivalent PCIe transactions. This would involve capturing the ISA DMA request signals and converting them to PCIe Transaction Layer Packets and then also be bi-directional. Which on a surface level wouldn't be that crazy hard. But once you get into the details of PCIe TLP and DMA, it becomes a real headache, and then doubles down because of the bi-directional nature. I don't see any real monetary benefit of such a bridge chip when it'd be far easier and cheaper to just user slightly older hardware or just use a FPGA. Though ISA is still heavily used in random areas, so maybe it is worth it for something this esoteric and niche to exist in quantity. I really hope the chip is finalized and does what it claims to do. It would be the best option for the foreseeable future imo.

LSS10999 wrote on 2025-04-18, 08:21:

From the datasheet you linked, it seems the net meant for so-called "LDRQ0#" actually connects to the PCH's GPP_A7/PIRQA#/GSPI0_CS1# (per 300 series datasheet).

I wonder what SuperIO would be using that pin for, as the PCH no longer provides any LDRQ# signal nor have any 8237 controller in it...

Maybe im misreading the 300 series doc you linked, but what I'm got out of it was that the LDRQ# line could be used by a SuperIO chip to request DMA services from the PCH. Then the PCH handles these requests with its modern implementation of DMA. This way legacy devices and software that expect DMA functionality would still work properly with modern hardware, maintaining the backward compatibility using updated hardware implementations. This would allow the removal of the 8237 controller from the PCH. Perhaps i'm being too wishful and am off base here, but that would be a really clever solution.

Potential PCIe-to-PCI-to-ISA pathway repository: https://github.com/DartFrogTek/PCIe-PCI-ISA

Reply 666 of 759, by robertmo3

User metadata
Rank Oldbie
Rank
Oldbie
Tiido wrote on 2025-04-18, 10:25:

VLB is a very big ask since it is mostly 386/486 CPU bus with a few extra signals. That is the main reason it disappeared when Pentium arrived.

there are socket 5 motherboards with vlb slots and socket 5 is a pentium socket
even socket 4 is a pentium socket

Reply 667 of 759, by Tiido

User metadata
Rank l33t
Rank
l33t

Yes, and they use large conversion chips to get VLB out of pentium's bus or maybe PCI, with worse performance than "native" VLB.

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 668 of 759, by RayeR

User metadata
Rank Oldbie
Rank
Oldbie
Metalliferous wrote on 2025-04-12, 20:26:

I'm compiling a list on Github here (fork from original repository): https://github.com/AranVink/dISAppointment
It's still a work in progress.

Please change the status of my MB Gigabyte GA-P67A-D3-B3, it should be in working section.
Here was a video prove it https://www.youtube.com/watch?v=ywgrP-Ki3v4
LDRQ mod link can be directed here http://rayer.g6.cz/hardware/gap67ad3.htm#LPC_LDRQ_MOD
and Free IRQ status - it works with IRQ5 that can be freed from LPT port. With IRQ7 it mostly doesn't work but in some rare occasions it works too, I never figured out why/what's happening but as IRQ5 works I don't bother anymore...

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 8GB DDR3, 128GB SSD, GTX970(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo + LPC2ISA

Reply 669 of 759, by RayeR

User metadata
Rank Oldbie
Rank
Oldbie
LSS10999 wrote on 2025-04-18, 08:21:

From the datasheet you linked, it seems the net meant for so-called "LDRQ0#" actually connects to the PCH's GPP_A7/PIRQA#/GSPI0_CS1# (per 300 series datasheet).
I wonder what SuperIO would be using that pin for, as the PCH no longer provides any LDRQ# signal nor have any 8237 controller in it...

Yes, it was discussed here some pages back: Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards
that LDRQ was removed since PCH 1xx series and whole LPC removed since 5xx series. So I doubt it would work on PCH 3xx. But on other hand when they wired it to PCH it should have some intention (PCB layout guys are lazy to wire traces that have no purpose 😀. Maybe they wanted to emulate LDRQ in SMM via SMI handler? Or has the PCH chipset some undocumented functionality that magically allows to unlock normally disabled ISA DMA block? (not removed in fact as HW but just disabled)?

BTW what VLB cards would one need to run on modern PC? In case of ISA soundcard it makes very sense but VLB? For some prehistoric 3D accelerator that can be emulated 100x faster?

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 8GB DDR3, 128GB SSD, GTX970(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo + LPC2ISA

Reply 670 of 759, by dartfrog

User metadata
Rank Newbie
Rank
Newbie
RayeR wrote on 2025-04-18, 16:01:
LSS10999 wrote on 2025-04-18, 08:21:

From the datasheet you linked, it seems the net meant for so-called "LDRQ0#" actually connects to the PCH's GPP_A7/PIRQA#/GSPI0_CS1# (per 300 series datasheet).
I wonder what SuperIO would be using that pin for, as the PCH no longer provides any LDRQ# signal nor have any 8237 controller in it...

Yes, it was discussed here some pages back: Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards
that LDRQ was removed since PCH 1xx series and whole LPC removed since 5xx series. So I doubt it would work on PCH 3xx. But on other hand when they wired it to PCH it should have some intention (PCB layout guys are lazy to wire traces that have no purpose 😀. Maybe they wanted to emulate LDRQ in SMM via SMI handler? Or has the PCH chipset some undocumented functionality that magically allows to unlock normally disabled ISA DMA block? (not removed in fact as HW but just disabled)?

From what I read in the LPC spec, the LDRQ# is dual purposed for ISA DMA and bus master request. If a device that wants to do direct memory access can do it with 8237 DMA controller or the LPC specific bus master protocol. Based on the LPC spec, any device which is bus master can DMA into the host memory. However, LPC DMA is not implemented on z390 apparently, the doc states "LPC no DMA". Just a bit weird for the mobo to have LDRQ# on a superio and routed to PCH if not implemented, i guess it's possible it's just leftovers, and no one thought to remove it? I guess it's possible that Intel does actually implement DMA with LPC on the PCH 3xx but that's not like Intel to lie in their datasheets. Generally for Intel, if it's undocumented it's not implemented and if it's stated to not have something it doesn't have it.

Some SuperIO datasheets do claim to have internal DMA buffers that simulate the function, but that would still require LPC with DMA which seems only implemented on PCH 1xx like you said.

Maybe they wanted to emulate LDRQ in SMM via SMI handler?

That's interesting. Basically firmware assisted pseudoDMA? Anyone up for some BIOS reverse engineering, 🤣

Or has the PCH chipset some undocumented functionality that magically allows to unlock normally disabled ISA DMA block?

Maybe it's one of the rare Intel Easter Eggs. I messed with chipsec and developed 2 scripts that would look for LPC DMA, and found some undocumented LPC DMA stuff. It's possible there might be something there! I've yet to full dive into the results but it's interesting you brought that up.

[*] Checking for unusual LPC register values... [*] Scanning for potential undocumented features... Register 0x80: 0x3F0F0070 Re […]
Show full quote

[*] Checking for unusual LPC register values...
[*] Scanning for potential undocumented features...
Register 0x80: 0x3F0F0070
Register 0x84: 0x007C0A01
Register 0x88: 0x000C0081
Register 0xD0: 0x00112233
WARNING: Potential DMA configuration detected in register 0xD0
Register 0xD4: 0x00004567
Register 0xD8: 0x0000FFCF
Register 0xDC: 0x00000080
Register 0xE0: 0x00000309
WARNING: Potential DMA configuration detected in register 0xE0
Register 0xF8: 0x01110FB5
WARNING: Found 9 non-standard register values that might indicate undocumented features

################################################################ ## # […]
Show full quote

################################################################
## ##
## CHIPSEC: Platform Hardware Security Assessment Framework ##
## ##
################################################################
[CHIPSEC] Version : 1.13.11
[CHIPSEC] Arguments: -m common.lpc_dma_z390_test

WARNING: *******************************************************************
WARNING: Chipsec should only be used on test systems!
WARNING: It should not be installed/deployed on production end-user systems.
WARNING: See WARNING.txt
WARNING: *******************************************************************

[CHIPSEC] OS : Windows 10 10.0.19045 AMD64
[CHIPSEC] Python : 3.13.2 (64-bit) - Enabled GIL
[CHIPSEC] Helper : WindowsHelper ([REDACTED]\chipsec_hlpr.sys)
[CHIPSEC] Platform: Desktop 8th Generation Core Processor (Coffeelake S 6 Cores)
[CHIPSEC] CPUID: 906EC
[CHIPSEC] VID: 8086
[CHIPSEC] DID: 3EC2
[CHIPSEC] RID: 0A
[CHIPSEC] PCH : Intel Z390 (300 series) PCH
[CHIPSEC] VID: 8086
[CHIPSEC] DID: A305
[CHIPSEC] RID: 10

[+] loaded chipsec.modules.common.lpc_dma_z390_test
[*] running loaded modules ..

[*] Running module: chipsec.modules.common.lpc_dma_z390_test
##################################################
# LPC DMA Testing Module
# Checks for undocumented DMA capabilities over LPC
##################################################
[*] Checking for DMA residue on channel 0...
DMA channel 0 count: 0xFFFF, status: 0xFF
[*] Checking for DMA residue on channel 1...
DMA channel 1 count: 0xFFFF, status: 0xFF
[*] Checking for DMA residue on channel 2...
DMA channel 2 count: 0xFFFF, status: 0xFF
[*] Checking for DMA residue on channel 3...
DMA channel 3 count: 0xFFFF, status: 0xFF
[*] Checking for DMA residue on channel 5...
DMA channel 5 count: 0xFFFF, status: 0xFF
[*] Checking for DMA residue on channel 6...
DMA channel 6 count: 0xFFFF, status: 0xFF
[*] Checking for DMA residue on channel 7...
DMA channel 7 count: 0xFFFF, status: 0xFF
[*] Testing Z390 LPC controller for undocumented DMA features...
[+] Found Intel LPC controller: VID=0x8086, DID=0xA305
[+] Confirmed Z390 chipset
WARNING: Potential DMA register found at 0xD0 = 0x00112233
[-] Register at 0xD0 is writable! Possible DMA control register.
WARNING: Potential DMA register found at 0xD4 = 0x00004567
[-] Register at 0xD4 is writable! Possible DMA control register.
WARNING: Potential DMA register found at 0xD8 = 0x0000FFCF
[-] Register at 0xD8 is writable! Possible DMA control register.
WARNING: Potential DMA register found at 0xDC = 0x00000080
[-] Register at 0xDC is writable! Possible DMA control register.
WARNING: Potential DMA register found at 0xE0 = 0x00000309
[-] Register at 0xE0 is writable! Possible DMA control register.
[*] Attempting to initiate DMA on channel 1...
DMA channel 1 status unchanged: 0xFF
[*] Attempting to initiate DMA on channel 3...
DMA channel 3 status unchanged: 0xFF

[*] Test Results Summary:
[+] No DMA residue found
WARNING: Found potential undocumented LPC DMA registers
WARNING: DMA controller did not respond to commands
WARNING: Potential DMA capabilities over LPC detected!

[CHIPSEC] *************************** SUMMARY ***************************
[CHIPSEC] Time elapsed 0.054
[CHIPSEC] Modules failed to run 0:
[CHIPSEC] Modules passed 0:
[CHIPSEC] Modules information 0:
[CHIPSEC] Modules failed 0:
[CHIPSEC] Modules with warnings 1:
WARNING: chipsec.modules.common.lpc_dma_z390_test
[CHIPSEC] Modules not applicable 0:
[CHIPSEC] Modules total 1
[CHIPSEC] *****************************************************************

Which is quite interesting results. I'll have to look for more information on this. I included the test scripts for anyone familiar with chipsec. It's kind of complicated to get chipsec built / requires drivers but anyone should be able to build and run it provided they follow chipsec's installation and driver build instructions. (python scripts but in txt format, need to be renamed to .py not .txt) (scripts get placed in 'chipsec-1.13.11\chipsec\modules\common' and ran with "python chipsec_main.py -m common.lpc_dma_check" and "python chipsec_main.py -m common.lpc_dma_z390_test")

Probably not worth pursuing on the PCH 3xx but it was worth a try. Still seriously interesting the trace exists and theres potentially undocumented DMA features on the z390. Maybe this will spark some insight by someone who knows more than me.

I do wonder if it's possible to do a driver-less and chipsec-less LPC DMA script check, so anyone could run it without requiring chipsec to find boards more easily. I'll have to look into that.

Potential PCIe-to-PCI-to-ISA pathway repository: https://github.com/DartFrogTek/PCIe-PCI-ISA

Reply 671 of 759, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
RayeR wrote on 2025-04-18, 16:01:

Yes, it was discussed here some pages back: Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards
that LDRQ was removed since PCH 1xx series and whole LPC removed since 5xx series. So I doubt it would work on PCH 3xx. But on other hand when they wired it to PCH it should have some intention (PCB layout guys are lazy to wire traces that have no purpose 😀. Maybe they wanted to emulate LDRQ in SMM via SMI handler? Or has the PCH chipset some undocumented functionality that magically allows to unlock normally disabled ISA DMA block? (not removed in fact as HW but just disabled)?

I think the only apparent thing that a SuperIO would use DMA (LDRQ#) for would be ECP parallel port.

If there's a board of 100-series chipset and onwards proven to have a fully functional ECP parallel port (with DMA) then it means ISA DMA may indeed be achievable through other means.

However, few boards at that point still expose parallel ports so it's not easy to verify...

Reply 672 of 759, by RayeR

User metadata
Rank Oldbie
Rank
Oldbie

I can only point there are newer MBs with paraller port like this one
https://www.gigabyte.com/Motherboard/Z370-HD3P-rev-10/sp#sp
but no details if supports ECP mode. I don't have acces to such new HW to investigate myself...
As I seen the crippled UEFI usually don't have any extra options for COM/LPT settings, maybe only enable/disable but no more. My classic Award BIOS has SPP/EPP/ECP and I/O+IRQ options for LPT.

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 8GB DDR3, 128GB SSD, GTX970(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo + LPC2ISA

Reply 673 of 759, by vsharun

User metadata
Rank Newbie
Rank
Newbie

Quite interesting.
I got Gigabyte Z170-HD3P boardview with LPT port on it which clearly stated it has LDRQ0. At the same time bios doc states no ECP support.
While having no luck finding boardview for Asus Z170M-E D3, manual states ECP/EPP support and no references for DMA channel.

Reply 674 of 759, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
vsharun wrote on 2025-04-19, 06:34:

Quite interesting.
I got Gigabyte Z170-HD3P boardview with LPT port on it which clearly stated it has LDRQ0. At the same time bios doc states no ECP support.
While having no luck finding boardview for Asus Z170M-E D3, manual states ECP/EPP support and no references for DMA channel.

It appears all those aforementioned Gigabyte boards wired SuperIO's LDRQ# signal to GPP_A7/PIRQA#/GSPI0_CS1#.

So the question would be whether their BIOSes have code to configure and drive this particular GPIO.

EDIT: On the other hand, I looked at the boardview of ASUS H170M-PLUS and it seems the LDRQ# signal on its SuperIO is NC.

(The boardview suggested its SuperIO model is NCT6793D, but I could only find a datasheet for NCT6796D which appears to have the same pinout in regards to the LPC portion. The LDRQ# signal on the SuperIO in question is pin 18.)

Reply 675 of 759, by vsharun

User metadata
Rank Newbie
Rank
Newbie

Digging down further with Grok/ChatGPT they pointed out that this case Z170's ECP + EPP and no explicit "ECP DMA" mean parallel port working in IRQ mode without DMA support.
Having on hand z87/b85 which UEFI clearly portray DMA channels mean it's definitely gone in 170 series in LPT section at least.

Reply 676 of 759, by RayeR

User metadata
Rank Oldbie
Rank
Oldbie

Is the GPP_A7/PIRQA#/GSPI0_CS1# signal at the same ball position as LDRQ on older PCH? If so, I think it's leftover that someone forgot remove that connectin in schematic...

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 8GB DDR3, 128GB SSD, GTX970(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo + LPC2ISA

Reply 677 of 759, by vsharun

User metadata
Rank Newbie
Rank
Newbie
RayeR wrote on 2025-04-19, 13:56:

Is the GPP_A7/PIRQA#/GSPI0_CS1# signal at the same ball position as LDRQ on older PCH? If so, I think it's leftover that someone forgot remove that connectin in schematic...

z170 has different pins layout to z97 both pattern and ldrq0 location

Reply 678 of 759, by dartfrog

User metadata
Rank Newbie
Rank
Newbie

You can largely ignore this post. I am including this write up for posterity. Might be useful to someone down the road. I've exhausted my knowledge and capabilities. It was fun messing with chipsec and DMA registers.

I made a much more comprehensive DMA over LPC test using chipsec. The overall goal is to determine whether Z390 (or other) chipsets contain undocumented DMA functionality similar to what was present in older H81 chipsets.
Note: It's likely not possible to change this script into a chipsec-less / chipsec-driver-less script. A driver is likely required with test mode on in windows or be on linux is the only way I see this being possible.
It has some linux tests but mainly windows as that's what I know best. I've yet to test on linux.

~

Main Tests and Checks:

LPC Controller Identification (check_lpc_controller):
Identifies the LPC (Low Pin Count) controller on the system
Verifies if it's a Z390 chipset by checking the vendor/device ID

Traditional DMA Register Testing (test_traditional_dma_regs):
Tests if the traditional 8237A DMA controller registers respond
Tries to read and write to the DMA command register
Checks the DMA status register

H81-style DMA Register Testing (test_h81_dma_registers):
Scans for potential hidden DMA registers in the Z390 chipset
Tests specific register offsets that were present in H81 chipsets
Checks if these registers return meaningful values (not all 0s or 1s)
Tests if the registers are writable

ACPI Table Inspection (inspect_acpi_tables_minimal, analyze_acpi_dump):
Dumps and analyzes ACPI tables for DMA-related entries
Looks for SystemMemory operation regions in DSDT that might map to DMA controllers
Searches for DMA-related keywords in ACPI tables

SMI Handler Inspection (inspect_smi_handlers, inspect_smi_handlers_safe):
Examines System Management Interrupt (SMI) handlers
Checks SMI control registers
Tests if SMI commands affect the potential DMA registers
Looks for SMI ports being configured

Platform-Specific Feature Scanning (scan_platform_specific_features, scan_platform_specific_features_enhanced):
Checks vendor-specific registers that might enable/disable legacy features
Scans PCI configuration space for interesting registers
Checks Super I/O chips which might control legacy DMA
Tests legacy DMA controller I/O ports and page registers

Safer DMA Testing (safer_dma_test, safer_dma_test_two):
Performs non-invasive analysis of potential DMA registers
Analyzes register bit patterns without triggering actual DMA operations
Tests incremental changes to single bits rather than complex patterns
Checks register relationships (if writing to one affects others)

System Monitoring (monitor_dma_during_system_events, poll_dma_registers, monitor_dma_registers_long_term):
Monitors DMA registers during normal system events (disk I/O, network activity, etc.)
Polls DMA registers continuously to detect changes
Sets up long-term monitoring to log DMA register values over time

Register Bit Analysis (analyze_register_bits):
Analyzes register bit patterns to understand their potential meaning
Looks for common bit patterns in DMA controllers (enable bits, busy bits, etc.)

The script contains a few advanced tests that are commented out or modified due to potential system instability:
try_h81_dma_activation: Attempts to activate DMA using H81-style registers
comprehensive_dma_test: Performs actual DMA transfers (marked as causing BSOD)
inspect_smi_handlers_direct: Uses direct memory scanning (causes system freeze)

~

Key Findings:

Traditional DMA Registers
The traditional 8237A DMA registers were tested but don't appear to be responsive.
All reads from traditional DMA ports returned 0xFF, indicating they might be disabled or not implemented.
The test reported "DMA1 Command Register does not respond correctly" when it tried to write and read back.

Hidden H81-style DMA Registers
The script found five potential hidden DMA registers at offsets 0xD0-0xE0 in the LPC controller.
All five registers returned non-zero, non-0xFF values and All registers were reported as writable, which is significant:
0xD0 (Control): 0x00112233
0xD4 (Status): 0x00004567
0xD8 (Transfer Count): 0x0000FFCF
0xDC (Address): 0x00000080
0xE0 (Descriptor): 0x00000309

Register Analysis
The control register (0xD0) bit pattern analysis suggests it has several active bits that align with typical DMA controller functions.
The status register (0xD4) shows patterns consistent with a DMA status register.
Writing test patterns to Address and Transfer Count registers showed they accept writes but with some bit masking, suggesting they're real functional registers.

System Monitoring
No changes were detected in these registers during normal system operations (disk I/O, network, audio, USB).
The polling test over 30 seconds showed the registers maintained constant values.
Long-term monitoring also showed the registers maintained constant values.

Super I/O Chip Findings
The test discovered a Super I/O chip (ID: 0x8688) with multiple logical devices using DMA channels.
This suggests the system does have DMA functionality, but it might be routed through the Super I/O chip.

ACPI and SMI Analysis
The ACPI dumps didn't reveal any SystemMemory regions mapped to DMA functionality.
The SMI (System Management Interrupt) tests didn't show any interactions with the potential DMA registers.

0xDC Section - Address Register and Transfer Count Register:
Initially, the address register at 0xDC contained 0x00000080
When attempting to write 0xAABBCCDD to the register, it read back as 0x0000008D
Similarly, writing 0x00001234 to the transfer count register resulted in a read-back value of 0x00009204

This behavior is consistent with a real hardware register that has:
Reserved/Hardwired Bits: Some bits in the registers appear to be hardwired or reserved for specific purposes, which is why the values written and read back are different.
Activity Bits: The change from 0x80 to 0x8D (specifically the addition of the 0xD bit) suggests that the register might have automatically set some status or control bits in response to being accessed.
Hardware Masking: The test identified that certain bits (0x00008030) were masked, meaning the hardware ignores attempts to change these bits or uses them for control purposes internally.

This behavior strongly indicates that these registers are connected to actual hardware functionality rather than being simple memory locations. Real hardware registers often exhibit these types of behaviors:
Bit Masking: Many hardware controllers mask out certain bits that are reserved for status or future use.
Side Effects: Simply reading or writing to hardware registers can have side effects, such as clearing interrupt flags or triggering state changes.
Auto-Increment: The change from 0x80 to 0x8D might represent an auto-increment function, which is common in DMA controllers where the address automatically advances after operations.

Comparison to Traditional DMA Behavior
This behavior is remarkably similar to how traditional 8237A DMA controllers operate. In classic DMA controllers:
Auto-initialization: After a DMA operation, certain bits in the status registers would be set automatically.
Address Modification: DMA controllers typically modify the current address register during operations, often incrementing or decrementing it based on transfer direction.
Read/Write Effects: Reading from or writing to certain registers can have side effects, such as clearing flip-flops or triggering state transitions.

The fact that the register changed from 0x80 to 0x8D after a write attempt strongly suggests that we're seeing actual DMA controller hardware responding, not just a memory location being used to communicate with firmware.
This supports the theory that the Z390 chipset has undocumented but functional DMA capabilities that could be activated through proper register manipulation, possibly with additional SMI handler involvement for more complex operations or for implementing functionality that was previously hardwired in older chipsets.

Overall Assessment
The script has found strong evidence of hidden, undocumented DMA-like registers in the Z390 chipset that appear to be similar to those in the H81 chipset. These registers:
Exist at the expected offsets (0xD0-0xE0)
Contain non-trivial values
Can be read and partially written to and read back reliably. However minimal or no changes. See 0xDC section.
Have bit patterns consistent with DMA functionality
Show certain limitations (bit masking) that would be expected of real hardware registers

However, these registers don't appear to be actively used during normal system operations, suggesting they might be:
Legacy registers kept for backward compatibility
Registers that need special activation sequences
Registers used only by system firmware/BIOS in specific scenarios

The warning in the conclusion is appropriate: "Found potential hidden H81-style DMA registers in Z390." The script detected what appear to be functional DMA control registers that aren't documented in public Z390 specifications.
The traditional 8237A DMA interface appears to be disabled or not implemented in this system, which aligns with Intel's move away from legacy DMA in modern chipsets, but the discovery of these hidden registers suggests some DMA functionality may still exist through alternative interfaces.

~

Conclusion:
The test results strongly indicate that Z390 chipsets contain undocumented DMA-like registers at the same offsets where H81 chipsets had DMA functionality. The key findings from the test and related research indicate:
Hidden Functional Registers: Intel appears to have maintained hidden DMA-like registers in the Z390 chipset that respond to reading and writing, even though official documentation states "LPC no DMA" for this chipset generation.
DMA Signal Traces: Z390 motherboards still have LDRQ# (DMA request) signal traces routed from the Super I/O chip to the PCH, suggesting hardware-level support exists despite official documentation.
The LPC-DMA Connection: According to the Low Pin Count bus specification, the LPC bus includes an "LDRQ#" signal which is "an output from a device that wants to perform direct memory access, either via the Intel 8237A compatible DMA controller, or the LPC-specific bus master protocol."
Firmware-Assisted DMA Emulation: The theory about SMM (System Management Mode) based emulation is plausible. Cr4sh found that SMI handlers in firmware can provide significant functionality through what's called "SMM callout," where System Management Interrupts allow privileged code execution.
Cr4sh's findings: https://web.archive.org/web/20221225012325/ht … lities.html?m=1
sentinelone SMM Bug hunting: https://www.sentinelone.com/labs/zen-and-the- … ulnerabilities/

Why This Might Exist
There are several possible explanations I see for these hidden registers:
Legacy Software Support: The registers might be maintained for compatibility with legacy software that expects traditional DMA functionality.
Firmware Implementation: Intel may be using System Management Mode (SMM) to implement DMA functionality in firmware rather than hardware, with these registers serving as an interface between the OS and SMM handlers.
Undocumented Features: Intel has been known to include undocumented modes in their chipsets, such as the "Manufacturing Mode" discovered in Intel ME that remains accessible if not properly disabled.
Chipset Reuse: There's speculation that Z390 is largely a rebranded Z370 with some additional features, which might explain why legacy hardware interfaces remain present but undocumented.

Technical Analysis of the Hidden Registers
The test found five specific registers that appear to function like classic DMA controller registers:
0xD0 - Control Register (value: 0x00112233): The bit pattern analysis suggests this controls DMA operations with fields for channel selection, direction, and operation mode.
0xD4 - Status Register (value: 0x00004567): Shows patterns consistent with status bits that might indicate transfer completion or errors.
0xD8 - Transfer Count (value: 0x0000FFCF): This appears to specify how many bytes to transfer, with some bit masking.
0xDC - Address Register (value: 0x00000080): Likely specifies source or destination memory address for DMA operations.
0xE0 - Descriptor Control (value: 0x00000309): Could contain additional configuration bits for advanced operations.

The "Firmware-Assisted PseudoDMA" Theory
The theory about firmware-assisted DMA through SMI handlers is particularly interesting. SMM code can perform privileged operations transparent to the operating system, triggered by writing specific values to port 0xB2 (the APMC port).
This would mean that what appears to be direct hardware DMA might actually be a more complex mechanism:
Software writes to these "DMA registers"
A subsequent trigger (perhaps a specific register write) causes an SMI
The SMI handler in firmware executes in SMM and performs the actual data transfer

This approach would allow Intel to maintain software compatibility with legacy DMA interfaces while leveraging more modern capabilities of the chipset.
This implementation would explain why the registers were detected as functional but didn't show activity during normal system operations - they might only be activated when specific access patterns occur or when the SMI handler is triggered.

~

Where to go from here:

Theoretically you could trigger the SMI handler and poll the DMA registers. I've yet to mess with this.
By using these techniques, you could safely probe the SMI handlers and DMA registers to see if they interact in ways that suggest hidden DMA functionality, all while minimizing risk to system stability.

The most common way to trigger an SMI is by writing a value to port 0xB2 (the APMC port). This is relatively safe as it's a standard method used by firmware.

Implement Safer Tests First: Start with tests that are less likely to cause system instability.
Register Monitoring: After each test, check register values to see if they've changed in ways that suggest activation.

Systematic Testing of SMI Commands: Test different SMI command values systematically (0x00 through 0xFF), starting with common values that are known to be safer.
Use ACPI Methods: Some ACPI methods might trigger SMIs more safely through structured interfaces.
Create a Polling Function: Set up a function to safely read the registers without attempting to modify them.
Monitor for Changes: Poll before and after each SMI trigger to detect changes.

Memory Buffer Preparation: Allocate a safe memory buffer for potential DMA operations.
Set Up a Monitor for Unexpected Changes.

~

If you read this entire post, I appreciate you.

~
Script output:

PS [REDACTED]\chipsec-1.13.11> python chipsec_main.py -m common.lpc_dma_h81_z390_test […]
Show full quote

PS [REDACTED]\chipsec-1.13.11> python chipsec_main.py -m common.lpc_dma_h81_z390_test

################################################################
## ##
## CHIPSEC: Platform Hardware Security Assessment Framework ##
## ##
################################################################
[CHIPSEC] Version : 1.13.11
[CHIPSEC] Arguments: -m common.lpc_dma_h81_z390_test

WARNING: *******************************************************************
WARNING: Chipsec should only be used on test systems!
WARNING: It should not be installed/deployed on production end-user systems.
WARNING: See WARNING.txt
WARNING: *******************************************************************

[CHIPSEC] OS : Windows 10 10.0.19045 AMD64
[CHIPSEC] Python : 3.13.2 (64-bit) - Enabled GIL
[CHIPSEC] Helper : WindowsHelper (\??\[REDACTED]\chipsec-1.13.11\chipsec\helper\windows\windows_amd64\chipsec_hlpr.sys)
[CHIPSEC] Platform: Desktop 8th Generation Core Processor (Coffeelake S 6 Cores)
[CHIPSEC] CPUID: 906EC
[CHIPSEC] VID: 8086
[CHIPSEC] DID: 3EC2
[CHIPSEC] RID: 0A
[CHIPSEC] PCH : Intel Z390 (300 series) PCH
[CHIPSEC] VID: 8086
[CHIPSEC] DID: A305
[CHIPSEC] RID: 10

[+] loaded chipsec.modules.common.lpc_dma_h81_z390_test
[*] running loaded modules ..

[*] Running module: chipsec.modules.common.lpc_dma_h81_z390_test
##################################################
# Z390 Undocumented DMA over LPC Test
# Checks for H81-style hidden DMA in Z390
##################################################
[*] Identifying LPC controller...
[+] Found Intel LPC controller: VID=0x8086, DID=0xA305
[+] Confirmed Z390 chipset
##################################################
TESTING --- test_traditional_dma_regs
##################################################
[*] Testing traditional 8237A DMA registers...
DMA1 Command Register initial value: 0xFF
DMA1 Command Register after write: 0xFF
WARNING: DMA1 Command Register does not respond correctly
DMA1 Status Register: 0xFF
##################################################
TESTING --- test_h81_dma_registers
##################################################
[*] Testing for H81-style DMA registers in Z390...
WARNING: Potential DMA register found: General DMA Control (0xD0) = 0x00112233
WARNING: Register at 0xD0 is WRITABLE - potential DMA control register!
WARNING: Potential DMA register found: General DMA Status (0xD4) = 0x00004567
WARNING: Register at 0xD4 is WRITABLE - potential DMA control register!
WARNING: Potential DMA register found: General DMA Transfer Count (0xD8) = 0x0000FFCF
WARNING: Register at 0xD8 is WRITABLE - potential DMA control register!
WARNING: Potential DMA register found: General DMA Address (0xDC) = 0x00000080
WARNING: Register at 0xDC is WRITABLE - potential DMA control register!
WARNING: Potential DMA register found: DMA Descriptor Control (0xE0) = 0x00000309
WARNING: Register at 0xE0 is WRITABLE - potential DMA control register!
##################################################
TESTING --- inspect_acpi_tables_minimal
##################################################
[*] Performing minimal ACPI table inspection...
Created directory: acpi_dumps for ACPI dumps
Running acpidump.exe to save ACPI tables...
Successfully saved ACPI dump (1719149 bytes) to acpi_dumps\acpi_dump.dat
##################################################
# Analyzing ACPI dump for DMA-related entries
##################################################
[*] Analyzing ACPI dump for DMA-related entries...
Analyzing ACPI dump file: acpi_dumps\acpi_dump.dat (1719149 bytes)
Found DSDT table at offset 444390
Extracted DSDT table to acpi_dumps\extracted_tables\DSDT.bin
No SystemMemory regions found in DSDT
##################################################
TESTING --- inspect_smi_handlers
##################################################
[*] Inspecting SMI handlers...
SMI handler inspection not available in this CHIPSEC build
SMI port 0xB2 current value: 0x52
Testing SMI command 0x4C...
Testing SMI command 0x4D...
Testing SMI command 0x51...
Testing SMI command 0x52...
##################################################
TESTING --- scan_platform_specific_features
##################################################
[*] Scanning for platform-specific DMA activation methods...
Found potential Root Complex Register register: 0x01100009
Found potential LPC Feature Control register: 0x00000309
WARNING: Register LPC Feature Control has bit 8 set, which might indicate legacy DMA support
##################################################
TESTING --- inspect_smi_handlers_safe
##################################################
[*] Safely inspecting SMI-related configuration (read-only)...
SMRAM control register: 0x00000000
SMI_EN register: 0x00000000
SMI_STS register: 0x00000000
APM status port (0xB3): 0x00
SMI-related inspection completed safely (read-only)
##################################################
TESTING --- scan_platform_specific_features_enhanced
##################################################
[*] Enhanced scan for platform-specific DMA activation methods...
Scanning Host Bridge: VID=0x8086, DID=0x3EC2
Interesting register at offset 0x40: 0xFED19001
Interesting register at offset 0x48: 0xFED10001
Interesting register at offset 0x50: 0x00000003
Interesting register at offset 0x54: 0x00000029
Interesting register at offset 0x58: 0x00000004
Interesting register at offset 0x5C: 0x3F000001
Interesting register at offset 0x60: 0xE0000001
Interesting register at offset 0x68: 0xFED18001
Interesting register at offset 0x70: 0xFE000000
Interesting register at offset 0x74: 0x00000007
Interesting register at offset 0x78: 0xFE000C00
Interesting register at offset 0x7C: 0x0000007F
Interesting register at offset 0x80: 0x11111111
Interesting register at offset 0x84: 0x00111111
Interesting register at offset 0x88: 0x0000001A
Interesting register at offset 0x90: 0xFE000001
Interesting register at offset 0x94: 0x00000007
Interesting register at offset 0x98: 0xBDF00001
Interesting register at offset 0x9C: 0x00000008
Interesting register at offset 0xA0: 0x00000001
Interesting register at offset 0xA4: 0x00000008
Interesting register at offset 0xA8: 0xBE000001
Interesting register at offset 0xAC: 0x00000008
Interesting register at offset 0xB0: 0x40000001
Interesting register at offset 0xB4: 0x40000001
Interesting register at offset 0xB8: 0x3F000001
Interesting register at offset 0xBC: 0x40000001
Interesting register at offset 0xE0: 0x01100009
Interesting register at offset 0xE4: 0x620120AD
Interesting register at offset 0xE8: 0xA4E400C8
Interesting register at offset 0xEC: 0x0002C000
Interesting register at offset 0xF4: 0x000C0FC8
Scanning PCI Express: VID=0x8086, DID=0x1901
Interesting register at offset 0x78: 0x00176200
Interesting register at offset 0x7C: 0x0A000000
Interesting register at offset 0x80: 0xC8039001
Interesting register at offset 0x84: 0x00000008
Interesting register at offset 0x88: 0x0000800D
Interesting register at offset 0x8C: 0x50001458
Interesting register at offset 0x90: 0x0000A005
Interesting register at offset 0xA0: 0x01420010
Interesting register at offset 0xA4: 0x00008001
Interesting register at offset 0xAC: 0x0261AD03
Interesting register at offset 0xB0: 0xD1010040
Interesting register at offset 0xB4: 0x000C2580
Interesting register at offset 0xB8: 0x00480000
Interesting register at offset 0xC4: 0x00080B80
Interesting register at offset 0xC8: 0x00006400
Interesting register at offset 0xCC: 0x0000000E
Interesting register at offset 0xD0: 0x001E0043
Interesting register at offset 0xF0: 0x00016000
Interesting register at offset 0xF4: 0x3201014E
Interesting register at offset 0xFC: 0x001000E0
Scanning LPC Bridge: VID=0x8086, DID=0xA305
Interesting register at offset 0x64: 0x000000D0
Interesting register at offset 0x80: 0x3F0F0070
Interesting register at offset 0x84: 0x007C0A01
Interesting register at offset 0x88: 0x000C0081
Interesting register at offset 0xD0: 0x00112233
WARNING: Potential DMA control register in LPC bridge: 0xD0 = 0x00112233
Interesting register at offset 0xD4: 0x00004567
WARNING: Potential DMA control register in LPC bridge: 0xD4 = 0x00004567
Interesting register at offset 0xD8: 0x0000FFCF
WARNING: Potential DMA control register in LPC bridge: 0xD8 = 0x0000FFCF
Interesting register at offset 0xDC: 0x00000080
WARNING: Potential DMA control register in LPC bridge: 0xDC = 0x00000080
Interesting register at offset 0xE0: 0x00000309
WARNING: Potential DMA control register in LPC bridge: 0xE0 = 0x00000309
Interesting register at offset 0xF8: 0x01110FB5
Scanning SMBus Controller: VID=0x8086, DID=0xA348
Interesting register at offset 0x48: 0x007B09FF
Interesting register at offset 0x50: 0xC0438001
Interesting register at offset 0x54: 0x00000008
Interesting register at offset 0x60: 0x00800005
Interesting register at offset 0x70: 0x00910010
Interesting register at offset 0x74: 0x10000000
Interesting register at offset 0x78: 0x00102800
Interesting register at offset 0x80: 0xF0146009
Interesting register at offset 0x84: 0x01400010
Interesting register at offset 0x8C: 0x000104A1
Interesting register at offset 0x90: 0x00080800
Interesting register at offset 0xC0: 0x21020608
Interesting register at offset 0xC4: 0x04806000
Interesting register at offset 0xC8: 0x82A50C00
Interesting register at offset 0xCC: 0x00030010
Interesting register at offset 0xD0: 0x02B50C00
Interesting register at offset 0xD4: 0x00030010
Interesting register at offset 0xF8: 0x01110FB5
Scanning EHCI Controller: VID=0x8086, DID=0xA360
Interesting register at offset 0x40: 0x90000255
Interesting register at offset 0x44: 0x80000000
Interesting register at offset 0x48: 0x06110506
Interesting register at offset 0x50: 0x40038C01
Interesting register at offset 0x54: 0x00000008
Interesting register at offset 0x60: 0x00000020
Interesting register at offset 0x64: 0x00004000
Interesting register at offset 0x6C: 0x00400000
Interesting register at offset 0x74: 0xE0000000
Interesting register at offset 0x8C: 0x0081A405
Interesting register at offset 0x90: 0xFEE003D0
Interesting register at offset 0xA0: 0x00000004
Interesting register at offset 0xA4: 0xF0140009
Interesting register at offset 0xA8: 0x01400010
Interesting register at offset 0xB0: 0x00008001
Interesting register at offset 0xB4: 0x000E0D38
Interesting register at offset 0xBC: 0x40000000
Interesting register at offset 0xF8: 0x01110FB5
Scanning for Super I/O chips...
Found Super I/O chip: ID=0x8688
Logical device 0: ID=0x01
WARNING: Logical device 0 is using DMA channel 7
Logical device 4: ID=0x01
WARNING: Logical device 4 is using DMA channel 4
Logical device 5: ID=0x01
WARNING: Logical device 5 is using DMA channel 4
Logical device 6: ID=0x01
WARNING: Logical device 6 is using DMA channel 4
Found Super I/O chip: ID=0xFFFF
Logical device 0: ID=0xFF
WARNING: Logical device 0 is using DMA channel 255
Logical device 1: ID=0xFF
WARNING: Logical device 1 is using DMA channel 255
Logical device 2: ID=0xFF
WARNING: Logical device 2 is using DMA channel 255
Logical device 3: ID=0xFF
WARNING: Logical device 3 is using DMA channel 255
Logical device 4: ID=0xFF
WARNING: Logical device 4 is using DMA channel 255
Logical device 5: ID=0xFF
WARNING: Logical device 5 is using DMA channel 255
Logical device 6: ID=0xFF
WARNING: Logical device 6 is using DMA channel 255
Logical device 7: ID=0xFF
WARNING: Logical device 7 is using DMA channel 255
Testing legacy DMA controller I/O ports...
DMA1 Status (port 0x08): 0xFF
DMA1 Command (port 0x08): 0xFF
DMA1 Request (port 0x09): 0xFF
DMA1 Mask Bit (port 0x0A): 0xFF
DMA1 Mode (port 0x0B): 0xFF
DMA1 Clear Flip-Flop (port 0x0C): 0xFF
DMA1 Master Clear (port 0x0D): 0xFF
DMA1 Clear Mask (port 0x0E): 0xFF
DMA1 Mask All (port 0x0F): 0xFF
DMA2 Status (port 0xC8): 0xFF
DMA2 Command (port 0xC8): 0xFF
DMA2 Request (port 0xC9): 0xFF
DMA2 Mask Bit (port 0xCA): 0xFF
DMA2 Mode (port 0xCB): 0xFF
DMA2 Clear Flip-Flop (port 0xCC): 0xFF
DMA2 Master Clear (port 0xCD): 0xFF
DMA2 Clear Mask (port 0xCE): 0xFF
DMA2 Mask All (port 0xCF): 0xFF
DMA Page Channel 0 (port 0x87): 0xFF
DMA Page Channel 1 (port 0x83): 0xFF
DMA Page Channel 2 (port 0x81): 0xFF
DMA Page Channel 3 (port 0x82): 0xFF
DMA Page Channel 4 (port 0x8F): 0xFF
DMA Page Channel 5 (port 0x8B): 0xFF
DMA Page Channel 6 (port 0x89): 0xFF
DMA Page Channel 7 (port 0x8A): 0xFF

[*] WARNING: Potential hidden DMA registers found.
Proceeding with non-invasive analysis only to avoid system instability.
##################################################
TESTING --- safer_dma_test
##################################################
[*] Performing safer DMA register testing...
[*] Monitoring DMA registers for passive changes...
[*] Initial register values:
ctrl: 0x00112233
stat: 0x00004567
tc: 0x0000FFCF
addr: 0x00000080
desc: 0x00000309
[*] Testing individual bits (safer approach)...
Testing bit 0: 0x00112233 -> 0x00112232
ISA DMA status: 0xFF
Testing bit 1: 0x00112233 -> 0x00112231
ISA DMA status: 0xFF
Testing bit 2: 0x00112233 -> 0x00112237
ISA DMA status: 0xFF
Testing bit 3: 0x00112233 -> 0x0011223B
ISA DMA status: 0xFF
Testing bit 4: 0x00112233 -> 0x00112223
ISA DMA status: 0xFF
Testing bit 5: 0x00112233 -> 0x00112213
ISA DMA status: 0xFF
Testing bit 6: 0x00112233 -> 0x00112273
ISA DMA status: 0xFF
Testing bit 7: 0x00112233 -> 0x001122B3
ISA DMA status: 0xFF
[*] Testing correlation with traditional DMA registers...
##################################################
TESTING --- safer_dma_test_two
##################################################
[*] Performing safer DMA register analysis...
Reading initial register values...
ctrl: 0x00112233
stat: 0x00004567
tc: 0x0000FFCF
addr: 0x00000080
desc: 0x00000309

Analyzing Control Register bit patterns:
Bit 0 (Enable/Start): 1
Bit 1 (Direction (0=Read, 1=Write)): 1
Bit 2 (Mode bit 0): 0
Bit 3 (Mode bit 1): 0
Bit 4 (Channel select bit 0): 1
Bit 5 (Channel select bit 1): 1
Bit 7 (Interrupt Enable): 0
Bit 8 (Auto-initialize): 0
Bit 16 (Burst mode): 1
Bit 31 (Master Enable): 0

Analyzing Status Register bit patterns:
Bit 0 (Busy/Complete): 1
Bit 1 (Transfer Complete): 1
Bit 2 (Error): 1
Bit 4 (Channel 0 status): 0
Bit 5 (Channel 1 status): 1
Bit 7 (Interrupt pending): 0

[*] Testing correlation with traditional DMA...
Setting traditional DMA channel 1 mode (no actual transfer)...
No register changes detected after DMA mode set

[*] Performing safe register modification tests...
Testing toggle of bit 8 in control register: 0x00112233 -> 0x00112333
Readback: 0x00112333, Status: 0x00004567
Testing toggle of bit 16 in control register: 0x00112233 -> 0x00102233
Readback: 0x00102233, Status: 0x00004567
Testing toggle of bit 24 in control register: 0x00112233 -> 0x01112233
Readback: 0x01112233, Status: 0x00004567

[*] Testing register relationships...
Writing test pattern 0xAABBCCDD to address register...
WARNING: Address register didn't accept write: wrote 0xAABBCCDD, read 0x0000008D
Writing test count 0x00001234 to transfer count register...
WARNING: Transfer count register behavior: wrote 0x00001234, read 0x00009204
Masked bits: 0x00008030

[*] Analysis Conclusions:
Likely register functions:
0xD0: Control register - contains mode/enable bits
0xD4: Status register - may indicate transfer status
0xD8: Transfer count - specifies bytes to transfer
0xDC: DMA address - source or target memory location
0xE0: Descriptor - may contain additional control bits
##################################################
TESTING --- monitor_dma_during_system_events
##################################################
[*] Setting up monitoring for DMA registers during system events...

Monitoring during Disk I/O...
Please open a file or folder in File Explorer...
Press Enter after performing the activity...
No register changes detected during Disk I/O

Monitoring during Network activity...
Please open a web page in your browser...
Press Enter after performing the activity...
No register changes detected during Network activity

Monitoring during Audio playback...
Please play an audio file...
Press Enter after performing the activity...
No register changes detected during Audio playback

Monitoring during USB device access...
Please plug in or access a USB device...
Press Enter after performing the activity...
No register changes detected during USB device access
[*] Polling DMA registers for 30 seconds...
Polling for 10.1s, 0 changes detected
Polling for 20.1s, 0 changes detected

[*] Polling Results Summary:
Total polls: 299
Total register changes: 0
Register ctrl remained constant at 0x00112233
Register stat remained constant at 0x00004567
Register tc remained constant at 0x0000FFCF
Register addr remained constant at 0x00000080
Register desc remained constant at 0x00000309
##################################################
TESTING --- monitor_dma_registers_long_term
##################################################
Starting long-term monitoring, logging to monitor_dma_registers_long_term.log
Press Ctrl+C to stop monitoring
Monitoring stopped by user

[*] Test Results Summary:
Traditional 8237A DMA registers do not respond
WARNING: Found potential hidden H81-style DMA registers in Z390
WARNING: Safe testing completed without attempting actual DMA transfers
WARNING: See log for detailed register analysis

[CHIPSEC] *************************** SUMMARY ***************************
[CHIPSEC] Time elapsed 101.342
[CHIPSEC] Modules failed to run 0:
[CHIPSEC] Modules passed 0:
[CHIPSEC] Modules information 0:
[CHIPSEC] Modules failed 0:
[CHIPSEC] Modules with warnings 1:
WARNING: chipsec.modules.common.lpc_dma_h81_z390_test
[CHIPSEC] Modules not applicable 0:
[CHIPSEC] Modules total 1
[CHIPSEC] *****************************************************************

Potential PCIe-to-PCI-to-ISA pathway repository: https://github.com/DartFrogTek/PCIe-PCI-ISA

Reply 679 of 759, by RayeR

User metadata
Rank Oldbie
Rank
Oldbie

Interesting findings. Further stap maybe dump/download UEFI flashrom image, unpack, try to find SMI handler module and disassemble it to see if it interacts with detected IO ports... Maybe intel implemented this with intention but UEFI writers didn't implemented it then as it would be low priority feature that most users don't need.

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 8GB DDR3, 128GB SSD, GTX970(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo + LPC2ISA