nakos1212 wrote on 2024-01-29, 18:00:

I inquiried Fintek for datasheets.
In the a meantime, a question:
Can this adapter be passed to a VM?

This adapter resides on the LPC bus and I don't think you can pass it to a VM.

On the other hand, there's this adapter, ISASTM, that could be passed into a VM such as PCem. You'll need a backplane for that adapter, however.

Thank you but its an 8 bit card and I am not sure that an Orpheus II will work on that...

nakos1212 wrote on 2024-01-29, 18:00:

I inquiried Fintek for datasheets.

Unlikely you will get a response other than them asking about the product you're designing. Also even if you did get the documents, they would be confidential, so you wouldn't be able to talk about them.

I know someone that gets sample chips all the time, and they claim the F85526 is available in their catalog through snail mail but it will take quite sometime for them to arrive, if they do at all. And if they do show up, I doubt there will be public documentation included. So it's unlikely that an open/publicly developed F85526 based adapter card is even an option. That is, unless Fintek releases the F85526 documentation publicly, which is doubtful since Fintek doesn't have other chips documentation public.He misread and has access to the F85226

~
The best bet I can think of, is reaching out to a consultancy group to develop a block diagram around the F85526 for the PCIe to ISA device and have them reach out to Fintek directly questioning the feasibility of the design. If the design is cleared by Fintek, then the next step would be to get the group to design a pcb based off the confidential F85526 documents and then spinning off a few test boards, which could be distributed in the community and if they worked as planned, they could be ordered easily.

Which that is exactly what I have requested from someone else that I know, they do consultancy pcb designs. I'm owed a big favor from them and I don't know where this will end up, but it will be interesting nevertheless!!

~
Update: Fintek hasn't finalized the F85526 and is unable to supply the chip or documentation to the consultancy fab yet. I was informed by my friend that such a bridge would possibly need external PHY hardware as well, depending on Fintek's implementation. Also that FPGA IP cores exist for such a bridge, but that seems expensive and complex. Well, that sucks. Looks like LPC/TPM/asrock motherboards are the only way to really do this currently.

Oh and I reached out to Asrock about the Intel Livemixer vs AMD Livemixer about an ISA bus over LPC, and they claim it would work on both AMD and Intel Livemixer motherboards because of the SuperIO NCT6686D and F85227N eSPI to LPC bridge on the AMD, and the NCT6796D eSPI to LPC on the Intel. Claiming it should theoretically would work on any of their motherboards with either of those chips. DMA is confirmed on the Intel board as well as the AMD. They couldn't supply a list of the boards which use the chips but claimed it's extensive and that results may vary due to board layout constraints (ie, probably need to solder on via/expose traces/lift pin). The thing I find interesting is that they claim the Intel board supports it, which is a 12-14th Intel board with DDR5. Would be really cool if it does.

Many Asrock boards have these exact SuperIO chips. What is specific about the livemixers?

dartfrog wrote on 2024-01-31, 12:04:

Oh and I reached out to Asrock about the Intel Livemixer vs AMD Livemixer about an ISA bus over LPC, and they claim it would work on both AMD and Intel Livemixer motherboards because of the SuperIO NCT6686D and F85227N eSPI to LPC bridge on the AMD, and the NCT6796D eSPI to LPC on the Intel. Claiming it should theoretically would work on any of their motherboards with either of those chips. DMA is confirmed on the Intel board as well as the AMD.

Hm, so it would mean that F85227N eSPI to LPC bridge provides LDRQ for DMA? Do they use any peripheral on the MB that needs legacy DMA? Otherwise I don't see any motivation why they should care. Is it some reliable info from engineers or marketing bla bla?

It is possible to put any hardware into the eSPI device, and this bridge can, in theory, just have entire ISA DMA controller in it, that is bridged with the LPC output. It has become possible to do that because it seems DMA controller is finally deleted from the main chipsets so the IO space is truly free for a new device to take its place. You could do this over PCIe directly too but you still need SERIRQ signal to target specific IRQs in way DOS(games) understand. PCIe has only single normal IRQ attached to it that suffers from same limits as regular PCI devices and the message IRQs that PCIe support are not compatible with ISA PIC way of things.

RayeR wrote on 2024-02-01, 14:19:

Hm, so it would mean that F85227N eSPI to LPC bridge provides LDRQ for DMA?

That seems to be the case, based on what the Asrock person said. I have problems with this though after some research. How the bridges were explained to me by my friend, is that the lpc bus basically gets clamped into an internal message within the eSPI bus as I/O transaction. Adding that you can access registers on peripherals connected though the LPC bus directly from the cpu using defined address spaces, so long as the bios has the range open. He claims it's not really on the bridge chip to do what we are asking, the but rather the bios letting us access the ranges we need.

What he said, kind of sounds like everything else, no DMA/Bus Mastering, but maybe i misunderstood him. If all that is true and i understand correctly, then I do suspect full ISA compatibility is actually dead via eSPI LPC bridge and the microchip/intel documents were right in not supporting DMA or Bus Mastering at all. I also suspect that the chips that claim they do dma and bus mastering don't actually do it...or maybe they do and im too dumb to understand how exactly. I know the LDRQ line is a request signal that a peripheral uses to tell the host it needs to do DMA and which channel it needs, or it's driven as a reserved word asking for Bus Mastering to do DMA peripheral to peripheral. Also the SYNC field ending the DMA. So maybe the eSPI bridge eats these requests and facilitates the DMA/Bus Mastering? I don't understand how you would know about the state of a DMA transaction or a Bus Master doing their thing, or even that either were initiated/abandoned/completed if the information isn't encoded in an eSPI I/O transaction. Maybe it can support it, but intel/microchip didn't because of performance or bloat reasons? but also if that's the case how do we even know the timing and structure of such an eSPI transaction if it's not in the eSPI standard and don't have the datasheet? i guess I need a new logic analyzer and to buy a few chips to probe to gather and decipher the message, if it exists 🤣. I doubt fintek is expanding the standard to support such features, but maybe they are. They seem to be the only place claiming support for it aside from FPGA IP stuff.

Honestly I'm just a tinkerer, and while I could implement i2c or spi in c or verilog, all these ISA/LPC/eSPI protocols are over my head and I naively thought this would be an interesting beginner project to get my feet wet in motherboard buses/protocols. I knew most of the chips datasheets, board files and information would be locked behind confidentiality agreements, but i didn't expect it to be this grim. I honestly thought someone would have found that F85227N eSPI LPC datasheet leaked from russia or somewhere or even chips for sale from china. But i can't find a single reference or chip to buy and probe that doesn't require a Chinese phone number (also they are like 85 dollars a piece 🤣). 🙁

I guess my only real option is to just bite the bullet and buy a mobo with those chips and test it... i have a feeling it's going to be bad news for dma though for some reason.

RayeR wrote on 2024-02-01, 14:19:

Do they use any peripheral on the MB that needs legacy DMA? Otherwise I don't see any motivation why they should care. Is it some reliable info from engineers or marketing bla bla?

I have no idea about legacy DMA, and maybe the contact from asrock was unreliable and it's untrue. However i do know the LiveMixer was going to have an addon card (shown on level1tech) that would expand the system over PCIe + eSPI/LPC (tpm). It was more a proof of concept than a product. I think wendell's motherboard was "modified" in the same way the other motherboards are for the hack here, with the NC pin some times being the LDRQ line needs bridging but I don't have one to test (yet).

also with this NC -> LDRQ 'hack' that some motherboards can do, has anyone mentioned value for pullup the LDRQ pins need? it's a 15k - 100k ohm pull up if not connected to anything. Would be a good way to find LDRQ lines, as there *should* be more than 1 since peripherals can't share LDRQ lines. Though, some hosts have these pullups internal so not a fool proof way. Ah yeah it was talked about already, but i don't think the values were specified.

Asrock seems to be one of the ones that generally just keep industrial designs and market them in both industrial and consumer markets. So consumers get lucky with legacy features. I remember getting a brand new ddr3 asrock mobo from my dad for a birthday or Christmas, mind you this was long after floppies fell out of fashion, blurays had come out a year or so ago, and the thing still had a floppy connector and the bios was set to recognize 5 1/4" drives. We both joked and laughed at it for a good while about why anyone would be using those floppies in that day and age. funny how i'll basically do anything for a modern pc with old connectors now.

dartfrog wrote on 2024-02-03, 10:40:

That seems to be the case, based on what the Asrock person said. I have problems with this though after some research. How the b […]
Show full quote

RayeR wrote on 2024-02-01, 14:19:

Hm, so it would mean that F85227N eSPI to LPC bridge provides LDRQ for DMA?

That seems to be the case, based on what the Asrock person said. I have problems with this though after some research. How the bridges were explained to me by my friend, is that the lpc bus basically gets clamped into an internal message within the eSPI bus as I/O transaction. Adding that you can access registers on peripherals connected though the LPC bus directly from the cpu using defined address spaces, so long as the bios has the range open. He claims it's not really on the bridge chip to do what we are asking, the but rather the bios letting us access the ranges we need.

What he said, kind of sounds like everything else, no DMA/Bus Mastering, but maybe i misunderstood him. If all that is true and i understand correctly, then I do suspect full ISA compatibility is actually dead via eSPI LPC bridge and the microchip/intel documents were right in not supporting DMA or Bus Mastering at all. I also suspect that the chips that claim they do dma and bus mastering don't actually do it...or maybe they do and im too dumb to understand how exactly. I know the LDRQ line is a request signal that a peripheral uses to tell the host it needs to do DMA and which channel it needs, or it's driven as a reserved word asking for Bus Mastering to do DMA peripheral to peripheral. Also the SYNC field ending the DMA. So maybe the eSPI bridge eats these requests and facilitates the DMA/Bus Mastering? I don't understand how you would know about the state of a DMA transaction or a Bus Master doing their thing, or even that either were initiated/abandoned/completed if the information isn't encoded in an eSPI I/O transaction. Maybe it can support it, but intel/microchip didn't because of performance or bloat reasons? but also if that's the case how do we even know the timing and structure of such an eSPI transaction if it's not in the eSPI standard and don't have the datasheet? i guess I need a new logic analyzer and to buy a few chips to probe to gather and decipher the message, if it exists 🤣. I doubt fintek is expanding the standard to support such features, but maybe they are. They seem to be the only place claiming support for it aside from FPGA IP stuff.

Honestly I'm just a tinkerer, and while I could implement i2c or spi in c or verilog, all these ISA/LPC/eSPI protocols are over my head and I naively thought this would be an interesting beginner project to get my feet wet in motherboard buses/protocols. I knew most of the chips datasheets, board files and information would be locked behind confidentiality agreements, but i didn't expect it to be this grim. I honestly thought someone would have found that F85227N eSPI LPC datasheet leaked from russia or somewhere or even chips for sale from china. But i can't find a single reference or chip to buy and probe that doesn't require a Chinese phone number (also they are like 85 dollars a piece 🤣). 🙁

I guess my only real option is to just bite the bullet and buy a mobo with those chips and test it... i have a feeling it's going to be bad news for dma though for some reason.

The 8237 DMA controllers are no longer mentioned in new chipsets as they move to eSPI.

It may be somewhat helpful if the I/O regions once claimed by 8237 are indeed freed in those chipsets. The problem, however, would be whether or not the CPU still somehow expose the necessary signal lines for connecting a 8237 implementation, such as HOLD, HLDA.

dartfrog wrote on 2024-02-03, 10:40:

RayeR wrote on 2024-02-01, 14:19:

Do they use any peripheral on the MB that needs legacy DMA? Otherwise I don't see any motivation why they should care. Is it some reliable info from engineers or marketing bla bla?

I have no idea about legacy DMA, and maybe the contact from asrock was unreliable and it's untrue. However i do know the LiveMixer was going to have an addon card (shown on level1tech) that would expand the system over PCIe + eSPI/LPC (tpm). It was more a proof of concept than a product. I think wendell's motherboard was "modified" in the same way the other motherboards are for the hack here, with the NC pin some times being the LDRQ line needs bridging but I don't have one to test (yet).

also with this NC -> LDRQ 'hack' that some motherboards can do, has anyone mentioned value for pullup the LDRQ pins need? it's a 15k - 100k ohm pull up if not connected to anything. Would be a good way to find LDRQ lines, as there *should* be more than 1 since peripherals can't share LDRQ lines. Though, some hosts have these pullups internal so not a fool proof way. Ah yeah it was talked about already, but i don't think the values were specified.

I wonder if there are some ways to inspect PCB traces without a boardview (considering boardview may or may not contain complete and correct information). From boards I could get boardviews on, NC pins are indeed NC pins and I have to actively look for test points or unpopulated resistor pads that would lead to a LDRQ#. Intel boards usually have two LDRQ# signals with the second one usually unused but exposed. Newer AMD boards (as of 400 series), however, have only one LDRQ# that is often hardwired to the SuperIO with no exposure, making the work difficult.

I don't know if there are really boards that are confirmed to expose LDRQ# directly on the TPM header (so no mod needed). Since TPM itself does not really use LDRQ#, it was rather uncommon for boards to actually expose it there.

And an off-topic idea: Don't know if it is possible to somehow interface ISA projects like PicoGUS directly against the LPC bus using using the TPM header pinout for connecting to the board. From what I read about PicoGUS and GUS in general, DMA was not mandatory for GUS to operate, and on PicoGUS DMA support is not 100% yet but is getting closer.

dartfrog wrote on 2024-02-03, 10:40:

Asrock seems to be one of the ones that generally just keep industrial designs and market them in both industrial and consumer markets. So consumers get lucky with legacy features. I remember getting a brand new ddr3 asrock mobo from my dad for a birthday or Christmas, mind you this was long after floppies fell out of fashion, blurays had come out a year or so ago, and the thing still had a floppy connector and the bios was set to recognize 5 1/4" drives. We both joked and laughed at it for a good while about why anyone would be using those floppies in that day and age. funny how i'll basically do anything for a modern pc with old connectors now.

Asrock indeed had a few boards that had traditional interfaces like Floppy and sometimes IDE. I don't know if such boards were commonly manufactured, as they appeared to be rare.

Some SuperIO chips do provide FDC that could be exposed so they work just like any board, but IDE is a different story if the chipset itself doesn't provide any. I have a board with an IDE port provided by a third-party chip, but when I was trying to connect an IDE optical drive to it, it was a real pain to get it work in DOS as well as in Win9x that I eventually gave up and used an IDE-SATA adapter instead, since neither DOS optical drive TSRs nor Win9x can detect it, and the third party IDE controller was obviously too new for Win9x to even have any driver. Of course, any third-party disk controller would by default bring in boot option ROMs that will permanently take up UMB space which is not desired if DOS is to be used, though not as much an issue with other OSes.

LSS10999 wrote on 2024-02-03, 16:30:

It may be somewhat helpful if the I/O regions once claimed by 8237 are indeed freed in those chipsets. The problem, however, would be whether or not the CPU still somehow expose the necessary signal lines for connecting a 8237 implementation, such as HOLD, HLDA.

These are transparently handled by the chipset on any type bus mastering accesses, so it shouldn't be any kind of concern. Any new DMA controller can access whatever memory it needs to and chipset simply provides the data requested data (or writes back data if such a DMA is performed). I'm unsure what caching related concerns are there but for our use case, which is sound cards, it isn't a problem.

It would be good to know if the IO ports are actually free or not on the new CPUs/chipsets, if yes, it is finally possible to fix this problem without needing custom possibly undocumented chips.

Are you sure that eSPI can handle all needed memory operations that legacy DMA did? So then some FPGA implementation of bridge with new legacy DMA would be possible? Doesn't sound as easy task. Maybe Fintek already did it in their new bridge?

LSS10999 wrote on 2024-02-03, 16:30:

sounds like everything else, no DMA/Bus Mastering
I do suspect full ISA compatibility is actually dead via eSPI LPC bridge and the microchip/intel documents were right in not supporting DMA or Bus Mastering at all
So maybe the eSPI bridge eats these requests and facilitates the DMA/Bus Mastering?

eSPI is Master/Slave, afaik cant have bus mastering over that without some explicit client side api/protocol.

nakos1212 wrote on 2024-01-29, 18:00:

I inquiried Fintek for datasheets.
In the a meantime, a question:
Can this adapter be passed to a VM?

Not related to this adapter, but if you require a motherboard with ISA passthrough capabilities, DFI has a Skylake motherboard with ISA slots, designed to work with KVM/QEMU via a proprietary software package.

DFI CS620-H310
https://us.dfi.com/product/index/1502

edit: it's a Coffee/Kaby Lake board

underage wrote on 2024-02-05, 11:05:

Not related to this adapter, but if you require a motherboard with ISA passthrough capabilities, DFI has a Skylake motherboard w […]
Show full quote

nakos1212 wrote on 2024-01-29, 18:00:

I inquiried Fintek for datasheets.
In the a meantime, a question:
Can this adapter be passed to a VM?

Not related to this adapter, but if you require a motherboard with ISA passthrough capabilities, DFI has a Skylake motherboard with ISA slots, designed to work with KVM/QEMU via a proprietary software package.

DFI CS620-H310
https://us.dfi.com/product/index/1502

Thank you, but that one cannot do DMA.
I wonder if its possible to write a TSR that captures DMA operations for these new boards though, there is one from MSi too. Some older PCI sound cards did have some emulation software/tsr attached.

nakos1212 wrote on 2024-02-05, 13:56:

Thank you, but that one cannot do DMA.
I wonder if its possible to write a TSR that captures DMA operations for these new boards though, there is one from MSi too. Some older PCI sound cards did have some emulation software/tsr attached.

Are you sure about DMA on this board? I had assumed that would be part of DFI's virtualization software package, otherwise an ISA bus shouldn't work on anything past Broadwell to begin with.

QEMU emulates an i440FX host PCI bridge with the PIIX3 PCI to ISA bridge. Maybe it would be possible to interface with segments of that emulation, in order to make a physical ISA bridge work in a virtualized environment.

If you look at the "tutorial" for the ISA passthrough, it only passes through base IO ports ans IRQ-s and the physical chips on the mobo dont support DMA either.

$5 LPC sniffer using Pico https://github.com/stacksmashing/pico-tpmsniffer

I resumed testing the AMD-side stuffs with a Socket FM2 platform, using the v0.2 board that's currently functional.

From what I noticed when experimenting with a debug card plugged into the ISA slot, it seems the Fintek bridge itself is operational on the LPC bus, but something is still missing on the chipset side.

- When the system starts up, the card could briefly pick up some very first post codes before stopped updating.
- LPC I/O decode for Port 80h is disabled by default, but can be enabled through one of the bits in the LPC bridge register 48h, and this bit does work as intended. After enabling this bit, whatever I wrote into Port 80h gets shown on the debug card.
- The alternative SuperIO config port (4Eh/4Fh) still can't work no matter what I do.

On the other hand... I'm not sure whether I've configured the chipset's Wide IO correctly... so perhaps I should just test it with a non-PnP sound card if possible, to see to how much extent the I/O decode ranges enabled can be accessed. I haven't modded the board I'm currently testing yet, but the board's LDRQ1# is easily accessible. LDRQ1# exists on older AMD platforms including FM2/Bolton FCH, just not on AM4.

EDIT: I'm using an ASUS board... The situation with LDRQ1# for FM2(+) boards is strange... other vendors such as ASRock simply left the LDRQ1# pin (AE27) totally NC with no way to access according to all the boardviews I could find.

Hm, it's interesting that your POST card show something at startup. Maybe picked some random noise/glitch at power up? Or have you seen more than one code? Always the same sequence? I cannot explain ho is it possible when the bridges are not configured by default to pass IO 80h. In my case the POST card was blind until I configured the bridge after boot and the I could send some outportb() to it and see the code...

Only posibility would be that BIOS of your board already contains some magic code to configure bridges - maybe some one prepared for a board with such isa bridge populated on.

BTW I have one Gigabyte SuperSocket 7 MB with Ali chipset and it sends POST codes only to PCI slots and not to ISA. 1st time I was a bit scared that MB/CPU is dead when can't see codes comming on post card plugged to ISA. For curiosity I swappwed card to PCI (it has both edge connectors) and yeah, codes shown up...

RayeR wrote on 2024-02-28, 16:37:

Hm, it's interesting that your POST card show something at startup. Maybe picked some random noise/glitch at power up? Or have you seen more than one code? Always the same sequence? I cannot explain ho is it possible when the bridges are not configured by default to pass IO 80h. In my case the POST card was blind until I configured the bridge after boot and the I could send some outportb() to it and see the code...

Only posibility would be that BIOS of your board already contains some magic code to configure bridges - maybe some one prepared for a board with such isa bridge populated on.

BTW I have one Gigabyte SuperSocket 7 MB with Ali chipset and it sends POST codes only to PCI slots and not to ISA. 1st time I was a bit scared that MB/CPU is dead when can't see codes comming on post card plugged to ISA. For curiosity I swappwed card to PCI (it has both edge connectors) and yeah, codes shown up...

It's always the same code (11 04). My debug card is 4 digit which shows the current (11) and previous (04) POST code. If the bridge was non-working then the card reads "----".

AMD Bolton FCH documentation stated the LPC port 80h decode bit is disabled by default... but this phenomenon seems to indicate otherwise -- that it was enabled right after powering up but disabled by BIOS shortly after. This most likely applies to other chipsets as well.

The Fintek bridge itself does not need to be configured. The ISA slot should be operational out-of-box as long as everything is set up correctly on the chipset side.

I've been looking at other Bolton FCH documentations to see if there is any hint about how to set up wide I/O ranges as well as the reasons why some bits don't work at all (such as 4Eh/4Fh) regardless of register settings. So far I haven't found anything helpful yet...

Hm, isn't that FCH bit strapped by some resistor (if there's such feature) to be force enabled? (and then disabled by BIOS)...