rasteri wrote on 2023-10-29, 13:40:

I wrote code to just spam reads to every port below 400, after running your program. […]
Show full quote

I wrote code to just spam reads to every port below 400, after running your program.

I don't know what flavour of LPC sigrok's decoder expects but it sure ain't the LPC that any of my motherboards speak. So these are transcribed by hand, and there may be mistakes.

If the port doesn't appear in this list then it doesnt get forwarded to LPC at all.

Copy code to clipboard

12E-2F - not aborted -- SUPER IO
24E-4F - aborted -- ISA BRIDGE
3
460 - not aborted -- KEYBOARD
562 - aborted
664 - not aborted -- KEYBOARD
766 - aborted
87E - aborted
97F - aborted
1080 - aborted
11EE - aborted
12EF - aborted
13
14200-20F - aborted
15
16220-28F - aborted
17290-297 - not aborted -- PART OF AudioPortEnable3?
18298--2ff - aborted
19300-308 - not aborted -- MIDIPortEnable0 PLUS A FEW MORE PORTS?
20309-3AF- - aborted
21
223BC-3BF - aborted
23
243E0-3F7 - aborted
253f8-3ff - not aborted -- SerialPortEnable0

I might try changing the address of the serial port in the BIOS to see if that causes a different range of ports to not be aborted.

Interesting... did you try this without running my program? I wonder if there are differences in aborting addresses before and after my configurations...

Btw as I read about sigrok - is LPC decoder supported in official version or do you need some unofficial fork? I tried to play a bit with sigrok at rasp.pico HW, probably most cheap analyser 😀

RayeR wrote on 2023-10-30, 11:33:

Btw as I read about sigrok - is LPC decoder supported in official version or do you need some unofficial fork? I tried to play a bit with sigrok at rasp.pico HW, probably most cheap analyser 😀

LPC is in the official version. It doesn't work, though - since I made that last post I've been through the python code and it needs to be substantially rewritten. I don't know if whoever wrote it just never tested it or if they tested it on a weird motherboard but the whole state machine is incorrect as far as I can tell.

And I'm using a Cypress FX3 dev board as my logic analyzer (plus some buffers) - Analyzing the ISA bus cheaply - 32 channels, max speed 192MHz (for 8 channels, though)

I did some tests on an AM3+ (990FX/SB950) board and sadly... it's still not detecting the bridge. Will be testing the adapters on my Intel boards when convenient... I've soldered a 8.2K between MASTER# and +5V under the ISA slot... so the boot issue should be taken care of.

EDIT: Just tested it on an Intel board and yes, the bridge's now properly detected, so the adapter itself is good now.

Configuration registers' default states looked largely similar to my AM4 boards, except it has an additional configured range in Wide I/O 2 as FF28 with alternative range bit set (FF28-FF2F perhaps). Wide I/O 0 is 0230 just like AM4.

Additionally, when I was testing the AM3+ board I noticed activities in the GPIOLPCCLK1 bit (register 7Dh, need to be read/written along with the TPM register that would be 7Ch), and by default the LPCCLK1ISGPIO bit was set which suggests the pin might be used as a GPIO rather than LPCCLK1 (for that the bit needs to be unset). I added the operation to unset that bit when configuring AMD chipsets in my program but it made no difference. I'm not sure if LPCCLK1 is really needed for the LPC-ISA bridge.

PS: I've overhauled my tool and split it into several different programs. The main program (lpcisa) no longer configures the LPC-ISA bridge as it's optional in most cases, including RUBY-9719VG2AR. Separate tools to check, inspect and configure LPC-ISA bridge have been made if one needs to make changes to the Fintek bridge.

Also, it appears old AMD/ATI chipsets used 1002 instead of 1022 so I have to make some changes to the chipset detecting logic to accept both vendor IDs for the AMD configuration subroutine.

BTW: A question about the -5V and -12V rail LEDs... On my v0.2 build these LEDs didn't work even though they were indeed correctly oriented (to be precise, the opposite direction of the positive voltage ones which are working), yet the PCI/ISA debug card I used for testing did pick up -12V from the ISA slot so the rail itself is probably okay (the card doesn't have -5V so I'm not sure about that one). I wonder if these negative volt rails require some special types of LEDs than normal ones...

LSS10999 wrote on 2023-11-12, 08:35:

I wonder if these negative volt rails require some special types of LEDs than normal ones...

No, leds just need to be correctly oriented.
You would have positive to the anode, and ground to the kathode
for negative voltage you have ground to anode, and negative voltage to kathode

if for a moment you look at the negative voltage as ground, then you see that the original ground is higher in potential, thus showing the correct orientation, from high to low.

+ -|>|- gnd -|>|- - (and a resistor for current limiting :-p )

LSS10999 wrote on 2023-11-12, 08:35:

they were indeed correctly oriented (to be precise, the opposite direction of the positive voltage ones which are working)

All the LEDs should point the same way, ironically I did that so people wouldn't have to second guess the orientation... Kicad's default libraries are horrible.

The negative end points towards the ] shaped bracket on the silkscreen.

On the attached picture, positive is left and negative is right, for all LEDs.

Modern ATX PSU usually don't provide -5V, it's obsolete and nobody use it now. -12V is used for RS232 so should be there. If you really need -5V then use 7905 regultor. It was also part of reason why I used onboard SMPS+linear reg. instead of relying on ATX PSU.

rasteri wrote on 2023-11-12, 14:29:

All the LEDs should point the same way, ironically I did that so people wouldn't have to second guess the orientation... Kicad's […]
Show full quote

LSS10999 wrote on 2023-11-12, 08:35:

they were indeed correctly oriented (to be precise, the opposite direction of the positive voltage ones which are working)

All the LEDs should point the same way, ironically I did that so people wouldn't have to second guess the orientation... Kicad's default libraries are horrible.

The negative end points towards the ] shaped bracket on the silkscreen.

On the attached picture, positive is left and negative is right, for all LEDs.

I followed the + mark on the PCB when soldering the LEDs... if all the LEDs are to point to the same direction then I've soldered the negative ones wrong...

It's not trivial to rework the LEDs at this point... so if the negative volt rails themselves are working without issues... I'll keep it this way for now.

LSS10999 wrote on 2023-11-12, 15:08:

I followed the + mark on the PCB when soldering the LEDs... if all the LEDs are to point to the same direction then I've soldered the negative ones wrong...

v0.3 is going to have better diode markings, as well as orient the capacitors so they're all pointing the same way too. Is this clearer?

rasteri wrote on 2023-11-12, 16:05:

LSS10999 wrote on 2023-11-12, 15:08:

I followed the + mark on the PCB when soldering the LEDs... if all the LEDs are to point to the same direction then I've soldered the negative ones wrong...

v0.3 is going to have better diode markings, as well as orient the capacitors so they're all pointing the same way too. Is this clearer?

I think this should be good enough to explain the LED orientation (that all 5 should point to the same direction). After all, the + mark on the PCB is misleading in your case.

LSS10999 wrote on 2023-11-12, 08:35:

Configuration registers' default states looked largely similar to my AM4 boards, except it has an additional configured range in Wide I/O 2 as FF28 with alternative range bit set (FF28-FF2F perhaps). Wide I/O 0 is 0230 just like AM4.

Additionally, when I was testing the AM3+ board I noticed activities in the GPIOLPCCLK1 bit (register 7Dh, need to be read/written along with the TPM register that would be 7Ch), and by default the LPCCLK1ISGPIO bit was set which suggests the pin might be used as a GPIO rather than LPCCLK1 (for that the bit needs to be unset). I added the operation to unset that bit when configuring AMD chipsets in my program but it made no difference. I'm not sure if LPCCLK1 is really needed for the LPC-ISA bridge.

Still... I'm yet to make any progress on AMD chipsets. The bridge cannot be detected on my AM3+ (SB950) board either. I'm starting to have doubts about the capability of AMD's LPC bridge...

Maybe AMD's ACPI implementation has the LPC bridge disabled?

Duffman wrote on 2023-11-13, 02:16:

Maybe AMD's ACPI implementation has the LPC bridge disabled?

No. The bridge (Device 14H Function 3) is still there as it's needed by SuperIO. The problem is that the bridge's functionality feels kind of castrated.

The IO Port Decode Enable register (44h) contained a lot of ranges, including those used by sound cards, but in reality most bits don't do anything.

The register itself does work, namely bits for KBC and probably a few others. If you unset the bit for KBC port then keyboard will stop working, which happened when I accidentally unset it during early experiments of my configuration program.

As for the IO/Mem Port Decode Enable register (48h), the bit responsible for enabling 4Eh/4Fh configuration register pairs appears to be already set by default, yet in reality the LPC bridge is not passing through any data to the ports.

The fact that on AMD boards, a Wide I/O range of 230h (perhaps 230h-3FFh) is being configured by default, even though most of that range is already being covered by respective bits in register 44h, seems to indicate something...

LSS10999 wrote on 2023-11-13, 03:46:

As for the IO/Mem Port Decode Enable register (48h), the bit responsible for enabling 4Eh/4Fh configuration register pairs appears to be already set by default, yet in reality the LPC bridge is not passing through any data to the ports.

The fact that on AMD boards, a Wide I/O range of 230h (perhaps 230h-3FFh) is being configured by default, even though most of that range is already being covered by respective bits in register 44h, seems to indicate something...

The LPC bridge does start to pass the data through, it's just aborting the write halfway through. It sounds a lot like subtractive decoding, which is a PCI thing.

I wonder if it's worth digging through PCI - maybe there's a virtual (or even real) device on the PCI/PCIe bus that's claiming those addresses.

I'll try and get logic analyzer logs before I run your program to see if that changes anything about which ports are aborted.

rasteri wrote on 2023-11-14, 17:59:

The LPC bridge does start to pass the data through, it's just aborting the write halfway through. It sounds a lot like subtractive decoding, which is a PCI thing.

I wonder if it's worth digging through PCI - maybe there's a virtual (or even real) device on the PCI/PCIe bus that's claiming those addresses.

I'll try and get logic analyzer logs before I run your program to see if that changes anything about which ports are aborted.

Come to think of it. Back then when I was trying to get PCI sound cards' legacy audio function working on AMD chipsets, it was impossible to do so.

The TSRs can load but games won't detect Sound Blaster at all, an even worse situation than Intel and nVidia (nForce) where at least FM can be played.

Probably has something to do with subtractive decoding. I did some search about it... looks like you need to set the bit 5 of the register 40h (as well as bit 7 of the register 4Bh) on device 14h, function 4 (PCI-PCI bridge). However, I don't know if this device (which would be 1022:790f) still exists in the AM4 CPU, though it was documented in at least up to AMD FCH (which I think is just before AM4).

LSS10999 wrote on 2023-11-15, 02:41:

Probably has something to do with subtractive decoding. I did some search about it... looks like you need to set the bit 5 of the register 40h (as well as bit 7 of the register 4Bh) on device 14h, function 4 (PCI-PCI bridge). However, I don't know if this device (which would be 1022:790f) still exists in the AM4 CPU, though it was documented in at least up to AMD FCH (which I think is just before AM4).

That does sound promising.

Alternatively I wonder if anyone at AMD would reply to us. I dunno who we'd even email about it though

rasteri wrote on 2023-11-15, 13:17:

LSS10999 wrote on 2023-11-15, 02:41:

Probably has something to do with subtractive decoding. I did some search about it... looks like you need to set the bit 5 of the register 40h (as well as bit 7 of the register 4Bh) on device 14h, function 4 (PCI-PCI bridge). However, I don't know if this device (which would be 1022:790f) still exists in the AM4 CPU, though it was documented in at least up to AMD FCH (which I think is just before AM4).

That does sound promising.

Alternatively I wonder if anyone at AMD would reply to us. I dunno who we'd even email about it though

I just checked on an AM4 system of mine... sadly no. The device (00:14.4) doesn't exist anymore. Not listed in lspci from Linux, and even my PCICMD from DOS couldn't see it either.

I wonder if something else has taken over its role since AM4 as it's still mentioned in up to Bolton FCH's documentations. It's indeed not mentioned anymore in AM4's PPR.

The only other component of device 14h is the SMBUS controller (00:14.0).

I have a couple of older AMD motherboards I might test on - one based on a geode, the other I think socket AM3. Certainly the geode has an LPC header, I'll check the AM3 one too

Tested this on my AM3 system (990FX/SB950) and the host PCI bridge (00:14.4) is there. The bits responsible for enabling subtractive decoding are set, however.

I wonder if I need to disable subtractive decoding for the host PCI bridge to allow LPC bridge access the addresses, or the issue might not be with subtractive decoding at all?

Considering my past experience with AMD/ATI chipsets and PCI sound cards with DOS TSR, I suspect what's causing the accesses to abort on the LPC bus is causing accesses to PCI sound cards' legacy functions (through TSR) to abort as well...

On the other hand, people have reported success with SBEMU on AMD chipsets (including AM4 ones), although it works in a way different from legacy PCI sound cards. I think I'll take a look at its code to see if there is any workaround involved for AMD chipsets. If not, then the "thing" that is interfering with LPC as well as legacy PCI sound cards does not appear to interfere with SBEMU at all...

LSS10999 wrote on 2023-11-18, 08:50:

On the other hand, people have reported success with SBEMU on AMD chipsets (including AM4 ones), although it works in a way different from legacy PCI sound cards. I think I'll take a look at its code to see if there is any workaround involved for AMD chipsets.

SBEMU uses 386+ I/O port trapping features on the CPU side, nothing is sent on the bus in respect to legacy I/O access. As for interfacing with adiuo cards, SBEMU does it basically the same way as any OS audio drivers would do, using BIOS/UEFI-configured memory/IO ranges and interrupts.

wbc wrote on 2023-11-20, 14:08:

SBEMU uses 386+ I/O port trapping features on the CPU side, nothing is sent on the bus in respect to legacy I/O access. As for interfacing with adiuo cards, SBEMU does it basically the same way as any OS audio drivers would do, using BIOS/UEFI-configured memory/IO ranges and interrupts.

I did take a peek at the code and for now I couldn't find anything chipset-specific, so this particular technique is mostly immune to chipset quirks, although there are still rough edges needed to be ironed out.

Still, I think I should check if there is anything security-related in AMD/ATi chipsets (as well as AM4 CPUs).