AMD PSP may hog some hardware addresses or what do you mean by security?

nakos1212 wrote on 2023-11-22, 09:44:

AMD PSP may hog some hardware addresses or what do you mean by security?

I mean if there's something in the chipset actively trying to interrupt (abort) I/O on unknown/undesired legacy address ranges, like how LPC writes were being aborted halfway. Something like a firewall which actively rejects traffic that were not explicitly authorized.

It kind of resembles the usual networking stuffs. The I/O (Mem) decode and address range registers define which ports the LPC bus should "listen" (open), but the "firewall" only permitted access to a select few ports, so I/O to non-permitted ports are blocked even though the ports in question are "open" on the LPC side, and I/O to permitted ports (such as KBC) will stop working if you "closed" the ports on the LPC side (by unsetting the respective bits).

AFAIK DOS TSRs for PCI sound cards do not work since at least AMD 700 series, and this probably holds true to earlier ATi ones as well. These chipsets predate PSP. On AMD chipsets, the TSR for PCI sound card loads fine (ESS for example), but games cannot properly communicate with it so they behave the same as if the TSR was not installed. The method used by SBEMU was somehow immune to it, though.

I cannot say about AMD PSP but intel ME shouldn't act like this. ME can directly communicate with eth. controller and capture some packets but it shouldn't actively block some IO or memory transactions if not remotely instructed to do this.

Assuming this is a subtractive decoding thing, maybe rather than disable subtractive decode we can reconfigure the PCI bridge to not claim the relevant ranges, and by default it should fall back to LPC? I'm not finding anything about it in the docs however

RayeR wrote on 2023-11-22, 16:17:

I cannot say about AMD PSP but intel ME shouldn't act like this. ME can directly communicate with eth. controller and capture some packets but it shouldn't actively block some IO or memory transactions if not remotely instructed to do this.

I don't think PSP has anything to do with this. AMD chipsets were known to interfere with legacy I/O, namely blocking legacy PCI sound cards' DOS capabilities, and that was on chipsets before PSP was a thing.

On the other hand, Intel and even nVidia (nForce) never interfered with legacy I/O. While there may be no SFX due to lack of working DMA translation, non-DMA stuffs like FM, MIDI worked fine and in some cases out-of-box (some vendors had certain legacy components exposed to legacy I/O ranges without requiring TSR).

Putting AMD-related experiments aside... I'm currently testing my v0.2 build on a different Intel board I'd like to use it on, and ran into a strange issue.

While my program can detect the F85226 bridge, the register values are messed up. Except register 05h which reads like xEh (with x keeps changing between like 0/1/3, definitely not normal), every other register of interest reads FFh. And of course, the sound card I plugged into the adapter for testing is not being detected, either. On my previous Intel test board I was able to correctly read the default register settings which was expected (same as RUBY-9719VG2AR), though I did not test actual sound cards on that board as I did not wire LDRQ#.

The board in question is X99-M WS. The boardview I found suggested its CPU_OV jumper (pin 2) is wired to the LDRQ#1 on the PCH (pin AA35, probably using it as a GPIO), so if everything's going smooth there would be no need to hardmod. Sadly, due to this problem I could not draw a conclusion whether the boardview is telling the truth. (NOTE: The boardview did not mention LDRQ#1 directly. I found it by looking at the PCH pin AA35 and followed the nets connecting to it)

Further inspecting the boardview I found that there are two other devices on the LPC bus (TPU, to be precise). I wonder if these TPUs are somehow conflicting with the LPC-ISA bridge's functionality... such as using the same 4E/4F register pair for configurations. On the other hand, assuming SuperIO chips (like NCT6791D) won't be conflicting with the LPC-ISA bridge regarding configurations, I wonder if strapping the bridge to use 2E/2Fh instead of 4E/4Fh (by populating R6 which was originally DNP) would work around the issue in this case.

I've also tried not wiring the LDRQ#1 (keeping the CPU_OV jumper at its default position), as well as actually wiring the GND (TPM pin 2) between the board and adapter. No difference. The registers are still messed up in the same manner, so these may be ruled out as possible causes.

PS: A side note... while I was testing that board I had some kind of accident -- after connecting the adapter to the board's TPM (including the supposed LDRQ#1 that is the CPU_OV) for the first time, its POST code stopped working (staying at 00), but the onboard LEDs suggested the boot sequence was still ongoing and after a while I got display output that appeared hung. My USB keyboard did not light up, and later on I realized the CPU fan was not even spinning (the heatsink was big enough to keep the CPU from overheating, however). Only after a CMOS clear did I recover from it, and I did not encounter the issue again when I reconnected the adapter... just that I'm now having the issue with the configuration registers messed up.

LSS10999 wrote on 2023-11-26, 11:50:

Further inspecting the boardview I found that there are two other devices on the LPC bus (TPU, to be precise). I wonder if these TPUs are somehow conflicting with the LPC-ISA bridge's functionality... such as using the same 4E/4F register pair for configurations. On the other hand, assuming SuperIO chips (like NCT6791D) won't be conflicting with the LPC-ISA bridge regarding configurations, I wonder if strapping the bridge to use 2E/2Fh instead of 4E/4Fh (by populating R6 which was originally DNP) would work around the issue in this case.

Yeah this sounds very much like there's another device on 4E/4F that's causing bus contention. It is possible that the motherboard has a superIO on both 2E/2F and 4E/4F - I've seen a few boards with this configuration. In that case moving the Fintek to 2E/2F ain't gonna help I'm afraid. But it's worth a shot.

On the other hand, you might be able to disable one of the onboard devices by lifting a pin, soldering a link or even removing the chip entirely.

PS: A side note... while I was testing that board I had some kind of accident -- after connecting the adapter to the board's TPM (including the supposed LDRQ#1 that is the CPU_OV) for the first time, its POST code stopped working (staying at 00), but the onboard LEDs suggested the boot sequence was still ongoing and after a while I got display output that appeared hung. My USB keyboard did not light up, and later on I realized the CPU fan was not even spinning (the heatsink was big enough to keep the CPU from overheating, however). Only after a CMOS clear did I recover from it, and I did not encounter the issue again when I reconnected the adapter... just that I'm now having the issue with the configuration registers messed up.

The superIO usually controls the fans, so yeah that would add futher evidence to our theory that the fintek is conflicting with a superIO.

rasteri wrote on 2023-11-26, 14:10:

Yeah this sounds very much like there's another device on 4E/4F that's causing bus contention. It is possible that the motherboa […]
Show full quote

LSS10999 wrote on 2023-11-26, 11:50:

Further inspecting the boardview I found that there are two other devices on the LPC bus (TPU, to be precise). I wonder if these TPUs are somehow conflicting with the LPC-ISA bridge's functionality... such as using the same 4E/4F register pair for configurations. On the other hand, assuming SuperIO chips (like NCT6791D) won't be conflicting with the LPC-ISA bridge regarding configurations, I wonder if strapping the bridge to use 2E/2Fh instead of 4E/4Fh (by populating R6 which was originally DNP) would work around the issue in this case.

Yeah this sounds very much like there's another device on 4E/4F that's causing bus contention. It is possible that the motherboard has a superIO on both 2E/2F and 4E/4F - I've seen a few boards with this configuration. In that case moving the Fintek to 2E/2F ain't gonna help I'm afraid. But it's worth a shot.

On the other hand, you might be able to disable one of the onboard devices by lifting a pin, soldering a link or even removing the chip entirely.

PS: A side note... while I was testing that board I had some kind of accident -- after connecting the adapter to the board's TPM (including the supposed LDRQ#1 that is the CPU_OV) for the first time, its POST code stopped working (staying at 00), but the onboard LEDs suggested the boot sequence was still ongoing and after a while I got display output that appeared hung. My USB keyboard did not light up, and later on I realized the CPU fan was not even spinning (the heatsink was big enough to keep the CPU from overheating, however). Only after a CMOS clear did I recover from it, and I did not encounter the issue again when I reconnected the adapter... just that I'm now having the issue with the configuration registers messed up.

The superIO usually controls the fans, so yeah that would add futher evidence to our theory that the fintek is conflicting with a superIO.

The board actually has two TPU chips (with the other one on the back side of the board) on the LPC bus, but the two doesn't appear to conflict. There's very little information available about those TPUs (boardview part number EPF035-CA2) so I can't know what exactly they are.

Will test what would happen if I switch the Fintek bridge to use 2E/2F when I have the chance. Looks like there are more obstacles than a mere LDRQ# signal for this adapter to be usable even on applicable Intel chipsets...

A side note: I also checked the boardview of X99-A WS (ATX variant) and found similar layout regarding LDRQ#1 on the PCH (wired to CPU_OV jumper). It's possible ASUS is using that pin as a GPIO toggle (for BIOS to enable selecting higher CPU voltage numbers) in several board models. However, the presence of conflicting components on the LPC bus is getting in the way.

Looks like X99-M WS (as well as other form factors) is a no-go. Just tried forcing the bridge to use 2E (by soldering a 10K to R6) instead of 4E for configurations. Nothing changed. I'm still getting the same behavior.

I guess the TPUs on that board are indeed in the way, and it has nothing to do with whether the adapter uses 2E or 4E for configuration... So... all my experiments so far are going nowhere. Will probably look for a Z97/H97 board that's not hard to mod (and without any "exotic" feature provided using a secondary SuperIO) to actually put the adapter into use...

On the AMD side, unless there's any clue about what exactly the mysterious "firewall" is and how to disable it, I doubt there would be any more progress in that direction...

PS: A few boards with very late nForce chipsets (mainly for AM2+/AM3 CPUs) appear to have TPM ports as well, but I couldn't find any useful datasheet for the MCP southbridges used so it's very unlikely to start any experiments...

rasteri wrote on 2023-09-07, 01:03:

I was wrong, the AMD motherboard (NO WORKY) is aborting the 0x4F read (i.e. asserting LFRAME) halfway through the cycle. I wonder why it would do that, and if it's the same for all addresses or just 4F...

I wonder if this is some subtractive decoding weirdness

turnaround (TAR) should be 2 cycles long according to LPC spec from intel and then device should place valid SYNC status to LPC bus

LSS10999 wrote on 2023-12-02, 10:15:

I guess the TPUs on that board are indeed in the way, and it has nothing to do with whether the adapter uses 2E or 4E for configuration...

This is interesting though - if your board has a superIO or TPM device that uses 4E/4F, that *must* mean it's possible to stop 4E/4F from aborting somehow.

rasteri wrote on 2023-12-04, 15:35:

LSS10999 wrote on 2023-12-02, 10:15:

I guess the TPUs on that board are indeed in the way, and it has nothing to do with whether the adapter uses 2E or 4E for configuration...

This is interesting though - if your board has a superIO or TPM device that uses 4E/4F, that *must* mean it's possible to stop 4E/4F from aborting somehow.

That board with TPU is an Intel X99 one. The TPU has nothing to do with TPM -- it's more about overclocking and is an ASUS thing.

On the other hand, my AMD test board (B450M-A) don't appear to have anything else on the LPC bus, but interestingly enough... before soldering the resistor to pull up MASTER# (which fixed the non-booting issue on Intel boards), the AMD test board always booted fine, with or without dISAppointment connected. It's as if for some reasons the AMD CPU/chipset was never bothered by it.

Some recent experiments...

On the AMD side, I just tested the 0.2 board on my B450M-A again and unfortunately the system is still not picking up the bridge even though it's modded to use 2E/2F instead of 4E/4F. I did check the wires again and should be correct... most likely for AMD something else is needed.

On the Intel side, I modded a Z97M Pro4 to bring out its LDRQ1# (an unpopulated resistor under the heatsink). I don't actually have Z97M Pro4's boardview but I have one for H97M Pro4, the PCB layout around the PCH is identical for both boards from the looks of it. However, when I connected a newly built 0.3 board I think I might have broken the motherboard. The board would not POST, the CPU fan spinned for a brief moment when powered on then stopped. It also briefly spinned when the board turned off as I powered off the PSU. The POST card I'm using suggested something wrong with the +5V which I'm not sure if it's related to the adapter, the PSU, or the LDRQ1# mod. I also tried disconnecting the adapter and cleared CMOS. It did recover and became able to boot for once, but stopped working again when I reconnected the adapter... and this time, no matter how hard I try the board still could not recover...

I did check all the connections on the board while soldering the 0.3 board and made sure everything's properly soldered... though I've no idea what might be causing the issue... Maybe I'll try the 0.2 board and see if the issue is with the new board (like the Fintek bridge or something), as well as compare the wires I used on my B85 board (minus LDRQ#) with which the 0.2 board worked, to see if I connected anything wrong (both ASRock boards and share the same TPMS layout). But still, I need to first check if I can make the board snap out of the erratic state it's been put in (so as to make sure the experiment did not hardbrick it).

By the way... is the 0.3 board on GitHub usable? The changes I could notice are capacitor orientations and adjustments in resistors, which actually added a connection to pull MASTER# up so I don't have to manually solder a resistor like in previous board versions. (EDIT: The LED orientation marker is not yet there but I soldered them correctly this time. All five LEDs are correctly lit when powered on.)

What are brief diffs v.3 to .2? Did you checked your MB TPM pinout if something is not accidentally shorted? As we know not all pins on TPM are wired the same, it's not tight standard.

Btw I just send a batch of my PCB designs to JLCPCB including my version of LPC2ISA so i hope a that I could test it soon on my gigabyte P67 (LDRQ mod already done).

RayeR wrote on 2023-12-11, 14:16:

What are brief diffs v.3 to .2? Did you checked your MB TPM pinout if something is not accidentally shorted? As we know not all pins on TPM are wired the same, it's not tight standard.

Btw I just send a batch of my PCB designs to JLCPCB including my version of LPC2ISA so i hope a that I could test it soon on my gigabyte P67 (LDRQ mod already done).

v0.3 apparently changed the arrangement of resistors and resistor arrays. MASTER# should be properly pulled up in this version through a 8.2K resistor array.

I did refer to the boardview when connecting respective wires. ASRock boards of that period use a 18-pin TPMS layout.

I still have wires (minus LDRQ#) on my B85M-ITX (also ASRock). Since it's using the same TPMS layout and the v0.2 board I built worked there, will take that board out again to double-check when I have time.

Ok, did you checked all LPC logic signals with scope to see if there are no some weird levels (out of logic thresholds) or glitches or ringing?
What does POST card shows? Any code or stops at some code?

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

By the way... is the 0.3 board on GitHub usable? The changes I could notice are capacitor orientations and adjustments in resistors, which actually added a connection to pull MASTER# up so I don't have to manually solder a resistor like in previous board versions. (EDIT: The LED orientation marker is not yet there but I soldered them correctly this time. All five LEDs are correctly lit when powered on.)

I'm afraid I haven't actually built a v0.3 yet. I'm currently very busy with work, I'll get back to it after xmas.

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

Some recent experiments... […]
Show full quote

Some recent experiments...

On the AMD side, I just tested the 0.2 board on my B450M-A again and unfortunately the system is still not picking up the bridge even though it's modded to use 2E/2F instead of 4E/4F. I did check the wires again and should be correct... most likely for AMD something else is needed.

On the Intel side, I modded a Z97M Pro4 to bring out its LDRQ1# (an unpopulated resistor under the heatsink). I don't actually have Z97M Pro4's boardview but I have one for H97M Pro4, the PCB layout around the PCH is identical for both boards from the looks of it. However, when I connected a newly built 0.3 board I think I might have broken the motherboard. The board would not POST, the CPU fan spinned for a brief moment when powered on then stopped. It also briefly spinned when the board turned off as I powered off the PSU. The POST card I'm using suggested something wrong with the +5V which I'm not sure if it's related to the adapter, the PSU, or the LDRQ1# mod. I also tried disconnecting the adapter and cleared CMOS. It did recover and became able to boot for once, but stopped working again when I reconnected the adapter... and this time, no matter how hard I try the board still could not recover...

I did check all the connections on the board while soldering the 0.3 board and made sure everything's properly soldered... though I've no idea what might be causing the issue... Maybe I'll try the 0.2 board and see if the issue is with the new board (like the Fintek bridge or something), as well as compare the wires I used on my B85 board (minus LDRQ#) with which the 0.2 board worked, to see if I connected anything wrong (both ASRock boards and share the same TPMS layout). But still, I need to first check if I can make the board snap out of the erratic state it's been put in (so as to make sure the experiment did not hardbrick it).

By the way... is the 0.3 board on GitHub usable? The changes I could notice are capacitor orientations and adjustments in resistors, which actually added a connection to pull MASTER# up so I don't have to manually solder a resistor like in previous board versions. (EDIT: The LED orientation marker is not yet there but I soldered them correctly this time. All five LEDs are correctly lit when powered on.)

A follow-up on my experiments (Intel side)...

My v0.3 build was indeed not operational (not detected) as I just tested it on my B85M-ITX, which has previously confirmed my v0.2 build was working... I suspect it might be the Fintek chip I used this time. I have two separate batches from different sources, one is F85226FG and the other F85226AF. The latter was the one used on the v0.2 build which worked, while the former is the one I tried this time which doesn't. I think I'll use the F85226AF ones on subsequent test builds...

The Z97M board I modded and used for further experiments has ended up dead. I did manage to get it booted yesterday. The BIOS reported its network adapter's MAC address was invalid. Since it was not on the latest BIOS I decided to flash the latest BIOS (using built-in Instant Flash) in hope to address the issues, but after Instant Flash finished, it stopped working completely after I pressed Enter to reboot. Fans no longer spin, and even flashing previous BIOS versions via flashrom using an external programmer failed to bring it back to life, either. I did not connect the bridge before or after flashing the BIOS during the period just to be safe.

And here's the worse thing. As I desperately tried getting that board booting, the PSU I've been using for the tests ended up confused and could not work properly anymore, likely due to my repeated power-cycling in order to force the board to hard-reset. When I tried booting my B85M-ITX with that PSU today it kept power-cycling in an endless loop. I eventually get the B85 board booted properly using a different PSU, but even with that PSU I could not boot the failed Z97M board -- the CPU fan does not even spin at all, unlike the previous one.

I'm going to take a break on this for a while... On the other hand, a little suggestion: I wonder if it's okay to adjust the board to use the surface-mounting (D2PAK/TO-263) variant of L7905 instead of the current TO-220-3 package, as apparently L7905 in this package would be the tallest component on the board and I find it difficult to solder it properly.

RayeR wrote on 2023-12-12, 02:52:

Ok, did you checked all LPC logic signals with scope to see if there are no some weird levels (out of logic thresholds) or glitches or ringing?
What does POST card shows? Any code or stops at some code?

I don't have a convenient tool for analyzing LPC signals at the moment... and about the POST card question... well... when I was diagnosing the board when it stopped booting completely after flashing a BIOS upgrade... no. POST card showed no code at all. On the other hand, a boot diagnosis device (which shows the current starting component instead of POST code) suggested the board's not starting up, while the previous indication of a +5V problem no longer appears.

Ou, sad story, maybe your bad PSU could kill the MB with voltage out of range on some rail? Any POST code without LPC bridge? I think that during normal flashing some parts of SPI flashrom are not overwritten. If there's not extra EEPROM for LAN it may use GBE region in main bios flashrom to stroe MAC etc and it might get corrupted. Also maybe the spi flashrom is faulty - I heard some story about such problem where flashrom pretend to be OK when reading at slow speed via programmer but it was failing at full speed so maybe you coul try replace it by some other chip. It's not needed to be exactly the same part no.

RayeR wrote on 2023-12-19, 05:12:

Ou, sad story, maybe your bad PSU could kill the MB with voltage out of range on some rail? Any POST code without LPC bridge?

No POST code at all, with or without the bridge. I don't think there's much I could do for that board. With my old PSU the fan would briefly spin, but with a new PSU the fan don't even spin at all.

The original test PSU was not faulty previously. I most likely have broken it when I power-cycled it too many times hoping to force the board to do a reset (power down then up afterwards), which would reset some states allowing the board to boot. I only managed to trigger the board to reset twice and it was the second time that I actually booted the board (without the LPC bridge), and I did some configurations and flashed new BIOS after which it stopped booting anymore...

I think I might have caused damage on the Z97M board by actually connecting the LPCPD# wire without thinking this time. On newer versions of the LPC bridge LPCPD# is not needed anymore and is connected to +3.3V via a pull-up resistor on the PCB. The reason was that on some boards the LPCPD# pin might not have been actually wired to the TPM header. It may be possible that the board's PCH might not like that pin being externally pulled up, as the boardview suggest TPM header's LPCPD# is wired to the PCH, yet it does not appear to have been wired to the SuperIO...

RayeR wrote on 2023-12-19, 05:12:

I think that during normal flashing some parts of SPI flashrom are not overwritten. If there's not extra EEPROM for LAN it may use GBE region in main bios flashrom to stroe MAC etc and it might get corrupted. Also maybe the spi flashrom is faulty - I heard some story about such problem where flashrom pretend to be OK when reading at slow speed via programmer but it was failing at full speed so maybe you coul try replace it by some other chip. It's not needed to be exactly the same part no.

I don't have any usable 25Q64 (8MByte) SPI flash at the moment... I think BIOS expects a flash ROM of matching size and would not accept larger ones such as 25Q128 (16MByte) which I do have.

I think flashrom would read out the flash after writing to check against the source file for any inconsistencies. If there were any inconsistency flashrom would have warned me, but it actually finished without any error (saying VERIFIED). I'm using a XTW100 that's converted to serprog for flashing the BIOS externally. That programmer supports mostly large SPI flash ROMs and can read/write much faster than a CH341A programmer.