Added full debugging of both Coreboot and SeaBIOS over serial, booted and saw that the bridge wasn't detected.
Transferred the SOM over to a TinyLlama, hooked up my MiniPCIe-to-PCIe and PCIe-to-PCI adapters and a video card. The PCIe-to-PCI adapter uses the exact same bridge chip. Then did a boot and collected debug output again. Got a video output and the debugging showed the bridge being detected.

This points to either a faulty bridge chip on the ITX board, or (more likely) something being wired incorrectly. Unfortunately I don't have any schematics for the adapter board (a Startech PEX1PCI1 (silkscreen says "9X118ETP V1.0") or any other application notes/schematics for the 118 chip at all, so looks like I'll have to do a painstaking reverse engineering of that adapter and compare it to my own schematics to see if I can find what I did wrong.

Eivind wrote on 2023-05-25, 21:35:

I'll have to do a painstaking reverse engineering of that adapter and compare it to my own schematics to see if I can find what I did wrong.

That didn't take long, but damn, I'd mislabeled the PCIe TX/RX diffpairs and connected them the wrong way. TX-to-TX and RX-to-RX. That doesn't work, obviously. 😣
I'll try some rewiring, but I have my doubts it'll work with these impedance-controlled high speed signals... More to follow.

Try as I might, I couldn't get this working having cut traces and bodge-rewired the TX/RX pairs. Sometimes the bridge would show up in the logs, but mostly not. No display output either.
I've done a whole lot of rework on the board, mostly having to do with the routing of the PCIe signals, but also adding an SD card activity LED (thanks to everyone discussing this in the TinyLlama thread!).
Version 1.1 of the board was ordered on Thursday, currently in production at JLC...

@Eivind

That's a shame.

I hope you have more luck with version 1.1

Update:
I got a new batch of boards in yesterday, and I'm happy to say PCIe-to-PCI works fine now! 🎉

What I've done:
- Installed Win98. NOT a fun thing to do, whichever path I took I always ended up with the USB stick I booted from being drive C:, and the internal SD card being drive D: (fdisk can't make D: an active partition). Had to make a VM, set up the drive in there and then copy the raw image over to an SD card
- Got most devices recognized in Device Manager
- Installed voodoo drivers and ran GLQuake 1.09 on my Voodoo3, got a solid "timedemo demo1" fps of ~70 in both 640x480 and 800x600. So, we're obviously CPU-bottlenecked, but that's fine and understandable given the CPU. The CPU was running at 500 MHz with a fan, no issues

What's left:
- Swapping the MS-DOS 6.22 virtual floppy in the SOMs ROM with a Win98 one. Will make preparing the SD card way easier.
- Installing the CS4237B chip and getting appropriate drivers running
- Testing audio sources
- Testing MIDI (RpiZero2 / wavetable)
- Testing the gameport (MIDI, joysticks)
- Testing COM ports / serial mice
- Testing real PS/2 devices (USB keyboard and mouse worked fine through the HIDman / CH559)
- Setting up ethernet drivers and testing
- Testing SATA devices
- Programming PWM fan speed settings and tachometer reading in the BIOS setup

Unfortunately, my PCI riser/extender combo didn't work. VGA cards weren't detected. I tried measuring continuity of all pins between the riser card and extender card, it all seemed ok but I'm still suspecting a signal issue. Back to the drawing board on that one. 😒

All in all, I'm pretty happy with the progress! Will post new updates as I go through the list above.

A couple of photos, please excuse the mess! 🤓

@Eivind

Good to hear the PCIe-to-PCI works properly now - I don't suppose I could have the schematic of it?

Does the IDE controller still have the yellow exclamation mark on it in win98 when booted of the SD card?

Something to note from my testing with win98 and SATA ports on my Q6000M system
Immediately after setup finished it would not boot into win98 and I just got a black screen. I suspect this is because of the default ESDI_506.PDR driver not understanding what SATA is or something.

I was able to boot into win98 safe mode and from there I installed rloew's TBPLUS package (If I'm not mistaken as far as I can tell this is his most recent IDE driver for win98 from 2015 before he moved on to his win98 AHCI driver) after installing TBPLUS the SATA ports work correctly.

edit:
PCI riser cable too long maybe?
Looking at the PCI slot keying the slot is 5v? or is it 3.3v? I get confused by the different PCI slot keys. which is the more recent PCI 5v or PCI 3.3V?

Duffman wrote on 2023-06-21, 01:14:

PCI riser cable too long maybe?

Yeah that might very well be it. Unsure how to proceed tbh, I might try to use ribbon cables with 1.27mm wire pitch instead of the current 0.635mm. Maybe the thicker wires and larger spacing between each wire will help... I don't want to make it shorter, I need ~30cm for it to fit in my A1P case.
Might have to look into other cases as well, I'm sure it would be easier to get a simple right-angle riser to work.

Duffman wrote on 2023-06-21, 01:14:

Looking at the PCI slot keying the slot is 5v? or is it 3.3v? I get confused by the different PCI slot keys. which is the more recent PCI 5v or PCI 3.3V?

The PCI slot is keyed for 5V signaling - notch on the side away from the card connectors. The reason for choosing this is that most older PCI cards we're interested in using are either 5V or "universal", ie., that they accept both 5V and 3.3V signaling. Universal cards have notches on both sides.

3.3V is the most recent standard, and a requirement for 66 MHz signaling. Afaik, not many of these were used for graphics cards - AGP and PCI-e took over before that.

Regarding the Win98 stuff and drivers - I'll dive down into that later this week, didn't get to spend much time on that yet.

Eivind wrote on 2023-06-21, 13:59:

Yeah that might very well be it. Unsure how to proceed tbh, I might try to use ribbon cables with 1.27mm wire pitch instead of the current 0.635mm. Maybe the thicker wires and larger spacing between each wire will help... I don't want to make it shorter, I need ~30cm for it to fit in my A1P case.

Do you think there's anything to be gained by adopting an approach similar to that used for UDMA/66, namely thinner individual wires, with signals interleaved with ground, to help preserve signal integrity? In that standard, they were able to achieve at least 100 MB/s with a cable length of just over 45 cm. If you provide power separately, it may not be too far-fetched.

640K!enough wrote on 2023-06-22, 05:53:

Do you think there's anything to be gained by adopting an approach similar to that used for UDMA/66, namely thinner individual wires, with signals interleaved with ground, to help preserve signal integrity? In that standard, they were able to achieve at least 100 MB/s with a cable length of just over 45 cm. If you provide power separately, it may not be too far-fetched.

Good point! Though, I'm starting to think signal integrity might not be the (only) issue here - I made a couple of really short cables (~6cm) and tested again with no luck. 🙁 I think I need to look closely at the design of the extender board itself.

@Eivind

You could try one of these chinese extension cables - https://www.ebay.com.au/itm/132778125970

Duffman wrote on 2023-06-22, 07:48:

You could try one of these chinese extension cables - https://www.ebay.com.au/itm/132778125970

Yeah, I guess I could. Though, it's still shorter than I'd like. But for a simple proof-of-concept, maybe it's a good idea.
My ideal extender would both be longer, and have two slots, not one. For that, I need an additional three signals not present on the motherboard slot (PCICLK1, /GNT1 and /REQ1). That's kinda why I opted for trying to make my own.

Windows 98 update:

I added FORMAT.COM from the Win98 cd to the Win98 boot floppy image, and embedded that into the SOM's ROM. Booted from the virtual floppy and managed to partition and format the SD card without issues.
Btw, this SD card is a 64GB SDXC variant. Just thought I'd mention that since I seem to recall people having issues with SDXC cards with the Vortex86DX / weeCee. Seems to work just fine with this setup.
Then I copied over the win98 folder from the cd to the SD card and installed Windows from there. After installation, I changed the PnP BIOS in Device Manager to "PCI Bus" to make Windows detect the hardware.
Next came rloew's TBPLUS drivers, Amigamerlin 3dfx drivers and tools, usb mass storage device drivers and an R6040 ethernet driver. All looks fine:

There's a duplicate "PCI Standard ISA bridge", but I'll look at that later.

Also, the SD card speed was quite hampered by its PIO mode:

..but after turning DMA mode on, it's much better:

@Eivind

Nice!
I'm curious to find out what its limits are, how well does it cope with Unreal or UT99?

Can you dump the PCI config?
use pci.exe from https://github.com/karcherm/dostools

Duffman wrote on 2023-06-22, 13:59:

Nice!
I'm curious to find out what its limits are, how well does it cope with Unreal or UT99?

I tried installing UT99, got stuck when trying to launch the game with a "Please insert the Unreal Tournament Disc One" error. Mounting the iso with Daemon Tools apparently didn't help. I'll come back to this later, got a bit sick of banging my head against the wall... 😁

Disruptor wrote on 2023-06-22, 15:53:

Can you dump the PCI config?
use pci.exe from https://github.com/karcherm/dostools

Sure!

00:00.0: id 17f3:6025, class 06/00/00
00:01.0: id 17f3:1031, class 06/04/00
bus 0 -> 1, downstream 2..2
forwarding MMIO f4000000..f60fffff (33M)
forwarding MEM f8000000..f9ffffff (32M)
INTA -> IRQ15
00:07.0: id 17f3:6011, class 06/01/00
00:07.1: id 17f3:6011, class 06/01/00
00:08.0: id 17f3:6040, class 02/00/00
10: PIO at 2000..20ff
14: MMIO at fa011000..fa0110ff (256)
ROM (disabled), area size 00010000 (64K)
INTA -> IRQ9
00:0a.0: id 17f3:6060, class 0c/03/10
INTA -> IRQ14
00:0a.1: id 17f3:6061, class 0c/03/20
10: MMIO at fa011100..fa0111ff (256)
INTB -> IRQ10
00:0c.0: id 17f3:1012, class 01/01/8f
10: PIO at 2410..2417
14: PIO at 2420..2423
18: PIO at 2418..241f
1c: PIO at 2424..2427
20: PIO at 2400..240f
INTA -> IRQ11
01:00.0: id 12d8:e113, class 06/04/00
bus 1 -> 2
forwarding MMIO f4000000..f60fffff (33M)
forwarding MEM 00000000f8000000..00000000f9ffffff (32M)
INTA -> IRQ15
02:04.0: id 121a:0005, class 03/00/00
10: MMIO at f4000000..f5ffffff (32M)
14: MEM at f8000000..f9ffffff (32M)
18: PIO at 1000..10ff
ROM (disabled), area size 00010000 (64K)
INTA -> IRQ0

Eivind wrote on 2023-06-22, 13:19:

There's a duplicate "PCI Standard ISA bridge", but I'll look at that later.

The duplicate "PCI Standard ISA brigde" seems to be intended behaviour of the Vortex86EX SoC. The PCI device address of the two devices identifying themselves as ISA bridge are device 7, subfunction 0 and device 7, subfunction 1. The limited datasheet you can obtain on the Vortex86 website documents exactly that: Device 7 is the "south bridge", and it contains of two functions, called "SB0" and "SB1".

It seems the chip has a lot of integrated ISA peripherals (up to 10 serial ports, a parallel port, a PS/2 keyboard/mouse port). It also provides a limited ISA bus for external ISA devices (xISA). It is possible that one of the two devices identifying as ISA bridge is used to connect the internal ISA-like peripherals to the host bus, and the other device is used to connect the xISA devices to the host bus, but this theory is pure guesswork.

I completely fail to understand why an operating system like Windows 95 cares about ISA bridges at all. Those devices will get initialized by the BIOS (if they need initialization at all), and after intialization, they will just forward all relevant PCI cycles to the ISA bus they control. Having more than ISA brige likely means that at least one of the bridges operatea in "additive decode" mode in which it needs to know what memory and port addresses are on the ISA bus provided by that bridge, and actively claims the cycle targeted to the bus. Only one ISA bridge can succesfully operate in "subtractive decode", which is a "catch-all" mode that forwards all cycles to ISA that are not claimed by any other PCI device. Yet, this is nothing Windows needs to care about. If windows tries to access an ISA card, the relevant bridge will forward the cycle to its ISA bus. The operating system can't even notice which of the ISA bridges forwards which cycle.

I can see only one point in Windows caring about ISA bridges: If there is no ISA bridge, Windows can skip scanning for ISA devices on the hardware detection wizard.

Thus it's very unlikely that the error on one of the ISA bridges will affect system operation. I expect this to be a cosmetic problem caused by the fact that Windows doesn't expect two ISA bridges in the same system.

@mkarcher: Thanks, that's interesting! I seem to recall mucking around with both SB0 and SB1 at one point when trying to figure out certain aspects of the BIOS, it might have been for reading and writing to the eeprom directly, don't remember exactly, it's been over a year (this board obviously uses a slightly modified version of the TinyLlama BIOS, which is again a modified SeaBIOS).

@Duffman: I got UT game-of-the-year edition to work - it seemed pretty smooth at 800x600. I'll dig out a better monitor (had some issues with overscan with the one I used today) and do some proper benchmarking tomorrow!

@Eivind

Nice!

When I get my wee86DX board built I think it'll perform pretty similarly to your board. my theory in the weecee's case is that it's not the Vortex86DX CPU thats too slow for the unreal engine, it's the 2D only volari Z9 GPU thats too slow.
I haven't built it yet, so I don't know for sure, it's just my theory.