rasteri wrote on 2023-08-07, 15:31:

LSS10999 wrote on 2023-03-26, 12:43:

By the way, it seems the executable I built with DJGPP (actually cross-compiled from Linux) doesn't run when JEMM386 is active.

On this AM4 motherboard I'm having similar issues running DJGPP-compiled code that uses CWSDPR0 for ring-0 DPMI (e.g. sapphisa, quake) when even himem is loaded. I have to put DOS=NOAUTO in config.sys to stop windows 98 loading himem (IO.SYS apparently does this automatically).

But in any case, the fintek isn't being detected by your LPCEXP utility or by sapphisa. I'll need to double check I didn't fry the chip.

Does your test board (A320M-K) also have the TPM selection toggle? The one that allows choosing whether to use a discrete or built-in (firmware) TPM.

I'm not sure how it works, but from what I tested on my Prime B450M-A, it'll automatically revert to firmware TPM option if a real TPM device is not detected. Yet, I couldn't find anything out of ordinary from related registers...

Normally once the bit enabling 4E/4F registers is set the Fintek chip should be accessible if nothing goes wrong. My LPCEXP should have already done that.

Did you recheck this on your existing (Intel) test boards? At least that should tell whether your Fintek chip is working or not.

LSS10999 wrote on 2023-08-08, 00:56:

Does your test board (A320M-K) also have the TPM selection toggle? The one that allows choosing whether to use a discrete or built-in (firmware) TPM.

Yeah I believe it does but I haven't messed with it yet - will have some time soon.

I've attached the output of your program if that helps.

rasteri wrote on 2023-08-08, 11:59:

LSS10999 wrote on 2023-08-08, 00:56:

Does your test board (A320M-K) also have the TPM selection toggle? The one that allows choosing whether to use a discrete or built-in (firmware) TPM.

Yeah I believe it does but I haven't messed with it yet - will have some time soon.

I've attached the output of your program if that helps.

Except the PCI control register the rest of your board's initial register states are the same as mine. In your case (0x4), the only bit set was enabling legacy DMA. Mine also had two ROM-sharing related bits set, making it 0x1C.

With IO/Mem decode register's initial state being like that... you should already be able to access 4E/4F. All LPCEXP did to that register was enabling the other two Wide I/O ranges (which were disabled and initially set to zero).

Tried my disappointment on a known-good intel motherboard - it is indeed broken.

Then I replaced the Fintek bridge, and it STILL doesn't work....

I've presumably broken a trace on the board or something, I didn't exactly store it well... Seems a little pointless to assemble another board when I have the v2 on the way so I'll pause the experiments for now.

LSS10999 wrote on 2023-08-08, 16:01:

With IO/Mem decode register's initial state being like that... you should already be able to access 4E/4F. All LPCEXP did to that register was enabling the other two Wide I/O ranges (which were disabled and initially set to zero).

The new boards arrived, and are working great on intel.

On AMD I'm getting the same error as before.

Curiously however, if I put an ISA test card in, it shows BIOS POST codes and anything else that gets sent to I/O port 0x80. This means the LPC bus and Fintek bridge must be working, just (presumably) not for ports 4E/4F.

I wonder if there's another device hogging those addresses, or if something else must be done to route them to the LPC bus.

rasteri wrote on 2023-08-15, 23:48:

The new boards arrived, and are working great on intel. […]
Show full quote

LSS10999 wrote on 2023-08-08, 16:01:

With IO/Mem decode register's initial state being like that... you should already be able to access 4E/4F. All LPCEXP did to that register was enabling the other two Wide I/O ranges (which were disabled and initially set to zero).

The new boards arrived, and are working great on intel.

On AMD I'm getting the same error as before.

Curiously however, if I put an ISA test card in, it shows BIOS POST codes and anything else that gets sent to I/O port 0x80. This means the LPC bus and Fintek bridge must be working, just (presumably) not for ports 4E/4F.

I wonder if there's another device hogging those addresses, or if something else must be done to route them to the LPC bus.

I wonder if actual ISA cards could already work at this point, now that you can see port 0x80 output on the ISA slot which would be behind the Fintek bridge. Changing registers on the Fintek bridge through 4E/4F is optional even on Intel boards.

I enabled pretty much all necessary mappings available on the AMD LPC bridge in LPCEXP, as well as setting the three wide I/O ranges to regions used by AWE32/64. AMD's documentation on the LPC bridge has not changed as far as I could tell, but documentations do not have to be 100% identical to the actual thing.

If you're getting FFFFFFFF from 4E/4F then it means the Fintek bridge is not reachable from that address on the board... I don't know if LPC devices have standards on certain registers like where to look for the device/vendor ID and such...

PS: Have you checked the BIOS setting about using firmware or discrete TPM? I'm not sure what would happen with a working dISAppointment connected to that port.

LSS10999 wrote on 2023-08-16, 00:55:

PS: Have you checked the BIOS setting about using firmware or discrete TPM? I'm not sure what would happen with a working dISAppointment connected to that port.

Yeah I've fiddled with all the TPM settings (and many others), no change.

However I think there might still be hardware problems, I connected it back to my intel board and it's failing intermittently.

I suspect these fintek chips - I've tried two different ones but they're both reused from previous boards. I have a fresh batch arriving soon hopefully.

New fintek chips work great on intel but no worky on AMD.

It's still passing port 0x80 to a test card but port 4E won't respond to anything.

I'm gonna break out the logic analyzer to see if the LPC commands are even being sent at all.

rasteri wrote on 2023-08-30, 12:03:

It's still passing port 0x80 to a test card but port 4E won't respond to anything.

AFAIK in the past some motherboard vendors including ASUS do have boards with TPM slots that double as a debug card connector when not using it for TPM, and they also made such debug cards before. Don't know if this also applies to newer motherboards.

rasteri wrote on 2023-08-30, 12:03:

I'm gonna break out the logic analyzer to see if the LPC commands are even being sent at all.

I've limited knowledge on how AMD's LPC bus operate behind the scenes, besides known documentations... so there may be something I have missed...

Rpi pico PIOs are fast enough to implement low level LPC protocol decoder/bridge, with it you would clearly see what is being passed.

Looks like the motherboard is sending on 4E and reading from 4F, but the fintek chip isn't responding. I wonder if there's something unusual about the packet format the motherboard is sending, or if there's bus contention or something (caused by super I/O?)

I'll have to analyze a working Intel motherboard so I know what a healthy sequence looks like.

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

One thing you can try is make the chip react to 2E+2F instead, by pulling pin 128 low, perhaps 4E+4F are indeed blocked by something... Assuming it is available. Both of these addresses are used by SuperIO components from what I have seen.

Tiido wrote on 2023-09-07, 03:33:

One thing you can try is make the chip react to 2E+2F instead, by pulling pin 128 low, perhaps 4E+4F are indeed blocked by something... Assuming it is available. Both of these addresses are used by SuperIO components from what I have seen.

Can more than one LPC device share the same register?

By the way, does LPC-based TPM use 4E/4F?

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

Maybe this is worth testing: Toggle the TPM option in BIOS to "Use discrete TPM" and see what's happening on the LPC bus when the board starts. ASUS' BIOS might be looking for something on the LPC bus to determine whether a known TPM module exists, and will switch the BIOS setting back to "Use Firmware TPM" if it could not find one.

I don't know the BIOS version your AMD board uses. Does that version predate "Win11 support"?

On further investigation the LPC aborting occurs on a port-by-port basis. Port 2F doesn't abort, but port 4F does.

I wonder if we're missing a register somewhere that enables 4F to be passed to the LPC bus. Or perhaps a PCI device is claiming 4F through subtractive decoding?

I have logic traces of boots with and without fTPM, I'll analyze them later

BTW moving the fintek chip to 2E/2F just returns zero (instead of FF), probably bus contention from the existing super IO chip

Also I should add that other ports (e.g. soundblaster base port at 0x220) also abort so this isn't just a problem with the port used for the fintek chip

LSS10999 wrote on 2023-09-07, 04:07:

Can more than one LPC device share the same register?

By the way, does LPC-based TPM use 4E/4F?

Sharing should not be possible, except maybe for reads and then it is sorta not a LPC spec compliant device.

2E+F and 4E+F are supposed to be safe haven ports for mobo things (chipsets I have looked at single them out for use with specifically for stuff like SuperIO chips), and TPM can count as such but I know no details. I tried to find some LPC TPM datasheets but they don't say anything about what addresses etc. they listen to.

rasteri wrote on 2023-09-07, 15:23:

Also I should add that other ports (e.g. soundblaster base port at 0x220) also abort so this isn't just a problem with the port used for the fintek chip

Since Ryzen the FCH is in the CPU not the chipset, so in theory the chipset you're using should not matter. I'm not sure about any possibly undocumented trait of these AMD processors.

Actually, 0x220 is handled by IO Port Decode Enable register, managed by 2 bits, one for 220-227 and the other 228-22F, and they are somehow listed as serial port addresses.

I recall seeing similar naming of IO ranges in Intel's datasheet as well -- these chipsets have a register (80H) with options for decoding 220-227 and 228-22F for COMA and COMB, but when I tried it on my RUBY-9719VG2AR it did not work. Probably I configured it wrong...

Did the ranges 220-22F have a known serial-related use case prior to Sound Blaster's existence?

LSS10999 wrote on 2023-09-08, 00:56:

Did the ranges 220-22F have a known serial-related use case prior to Sound Blaster's existence?

I have some industrial motherboards with like 30 serial ports that put one of them at 220, but I've never seen a normal motherboard do it.

I'm not sure what else to try now - I guess I need to start randomly messing with registers and address decoding and see what affects the packets that appear on the LPC bus.

I may shelve this project for a while, I've been neglecting my other projects (HIDman) and I wanna get a video out.