Say is the v0.3 version of PCB actually usable?

Just built another v0.3 board using a F85226AF instead of F85226FG, yet it still doesn't work correctly. I inspected the job with a loupe and could not find anything that looks like bridges and such.

When I tested the v0.3 board with the X99M Killer 3.1, it instead made the SuperIO crazy (HW monitor shows strange values for fan speed and USB keyboard stops working as soon as it entered FreeDOS which is also booted from a USB stick), though fortunately it did not break the board this time. Putting the working v0.2 board back and everything's normal... though I'm still in the process of looking at why ISA sound cards are not working on this board even after I set everything up the same way as I did with my RUBY-9719VG2AR...

EDIT: Even my non-PnP CT3110 (SB 16 variant) can't be detected here... Maybe I need to change some other registers...

RayeR wrote on 2024-03-16, 15:26:

I made miniPCIe to PCIe x1 adapter for tinyLlama, not tested yet... Hm, miniPCI woul be a much more wires but less speed... coul be doable on a 4L PCB..

I actually finished the design of some miniPCI adapters (attached pic), I haven't actually ordered them though. I'm just using 2layers but keeping all traces super short to hopefully sidestep any issues. I've seen other people do PCI routing on 2layer boards so I think it should be possible.

LSS10999 wrote on 2024-03-22, 01:11:

I just did some further tests on the supposedly working dISAppointment and found out it might not be 100% usable. This might have also rendered several questions I posted before invalid...

I forget - have you ever had it working on any motherboard? It could be something as simple as a dodgy solder joint on one of the address lines or something. (yeah probably not if you've built loads of these things)

I haven't connected LDRQ# yet, as I need to remove the heatsink and solder a wire underneath it to bring out the unused LDRQ1#. However, I don't think a working ISA DMA is required for ISA PnP detection.

No, DMA isn't required for detection. What are you using to test? I did most of my testing with SBDIAG from the Snark Barker project, if you have a soundblaster that doesn't require init that's a good way of verifying all the different functionalities seperately

LSS10999 wrote on 2024-03-23, 07:56:

Say is the v0.3 version of PCB actually usable?

I'm afraid I've never tested 0.3, I have no reason to think it's broken but I can't be 100% sure. 0.2 is the last one I've tested and got 100% working. (sorry but I don't actually have any space to assemble stuff at the moment, assume everything in the repository is in a constant state of flux until I actually release v1.0)

DutchComputerKid wrote on 2024-03-22, 08:04:

Ah a D2D, so with tinyBIOS, you likely wont get any VGA support at all. You have to use one with Award for that. TinyBIOS throws everything over the serial port.
Propreitary PCEngines firmware, so it likely wont work at all.

Well I suppose I don't need VGA to test soundcards.... Seems like there's TinyBIOS source code available though, or maybe I can adapt coreboot or some other geode BIOS

rasteri wrote on 2024-03-23, 16:20:

I'm afraid I've never tested 0.3, I have no reason to think it's broken but I can't be 100% sure. 0.2 is the last one I've tested and got 100% working. (sorry but I don't actually have any space to assemble stuff at the moment, assume everything in the repository is in a constant state of flux until I actually release v1.0)

Okay, I got it. So far I've two v0.3 builds and neither worked correctly.

My v0.2 build is also usable. The LPC bridge can be detected correctly, and POST card attached to the ISA slot works and can output port 80h data, just that I can't get any sound card to be detected at the moment.

Don't know if chipsets like X99 needs something more. Guess I'll have to do a register dump of RUBY-9719VG2AR and my X99M Killer 3.1 to see if there's anything else that's relevant to LPC bridge's functionality...

LSS10999 wrote on 2024-03-24, 01:11:

Okay, I got it. So far I've two v0.3 builds and neither worked correctly.

Hey I did find one potential source of problems in 0.3. In the old version, all resistor packs shared a common VCC or GND. Now some packs have different pins pulled to VCC/GND. I've attached schematics showing what I mean.

This means that any bridged pins in those packs will cause problems now, whereas before it would have been fine (all my disappointment builds have bridges coz I'm lazy, 🤣).

Maybe not what your problem is but something to be aware of.

rasteri wrote on 2024-03-29, 20:59:

Hey I did find one potential source of problems in 0.3. In the old version, all resistor packs shared a common VCC or GND. Now s […]
Show full quote

LSS10999 wrote on 2024-03-24, 01:11:

Okay, I got it. So far I've two v0.3 builds and neither worked correctly.

Hey I did find one potential source of problems in 0.3. In the old version, all resistor packs shared a common VCC or GND. Now some packs have different pins pulled to VCC/GND. I've attached schematics showing what I mean.

This means that any bridged pins in those packs will cause problems now, whereas before it would have been fine (all my disappointment builds have bridges coz I'm lazy, 🤣).

Maybe not what your problem is but something to be aware of.

My v0.2 build did have some bridges back then, though I only fixed a few that really matters (according to the PCB file). POST card does work and can output debug status values, however.

I ended up building another v0.2 unit with F85226FG and this time I'm getting some better results on my test board (X99M Killer/3.1). UNISOUND still cannot pick up my YMF718 but my SB16 (CT2950) gets picked up and configured.

However, it's still not enough as DIAGNOSE is complaining about IRQ not working. I'm thinking about testing IRQ/DMA with DIAGNOSE in this case, since if DIAGNOSE can actually set them, then IRQ/DMA is definitely functional. I've already brought out LDRQ1# from beneath the heatsink to the adapter using a wire, but with IRQ test failing I cannot test if LDRQ1# is really working...

On the other hand, CTCM (Creative's PnP setup) cannot work here as it would throw an error about data checksum errors, despite UNISOUND configured it fine. And this X99-based board is too new for AIDA16 and HWINFO as well...

I also did a test with DIGPAK (THEAUDIO). MIDI (330h) and FM (388h) are working via SETM, but SFX via SETD does not (hangs). Not sure if this is due to IRQ or DMA as SETD does not ask me about those...

PS: The version register value appears to differ between my F85226FG and F85226AF. The former has a value of 10h while the latter has a value of 50h. The differences between chip versions, however, are not clearly documented AFAIK...

PPS: I dumped the registers of the host LPC bridges of my boards, including RUBY-9719VG2AR, so I could diff them to see what might matter. This probably has something to do with SIRQ control or PIRQ tables, but so far I haven't made more progress... I think I should boot into a Linux distro to check which device is taking up the IRQ I need. Sadly, on newer BIOSes it's no longer possible to reserve IRQ for such niche purposes anymore...

EDIT: Nope... Linux distro is not helpful as it only shows actual (APIC) interrupts. I need some kind of DOS tools to tell me which device taking up which IRQ before APIC...

LSS10999 wrote on 2024-03-31, 11:16:

but with IRQ test failing I cannot test if LDRQ1# is really working...

ehm... fyi

LPC Serial DMA/Master Request Inputs: LDRQ[1:0]# are used to request DMA or bus master access.

weedeewee wrote on 2024-03-31, 11:48:

LSS10999 wrote on 2024-03-31, 11:16:

but with IRQ test failing I cannot test if LDRQ1# is really working...

ehm... fyi

LPC Serial DMA/Master Request Inputs: LDRQ[1:0]# are used to request DMA or bus master access.

Those chipsets usually have two LDRQ# signals.

LDRQ0# is usually wired to SuperIO regardless of whether it's actually being used.

LDRQ1#, however, is unused in most cases. On most boards it's either routed to an unpopulated pull-up resistor (against +3V) or not exposed at all (NC).

LSS10999 wrote on 2024-03-31, 12:34:

Those chipsets usually have two LDRQ# signals. […]
Show full quote

weedeewee wrote on 2024-03-31, 11:48:

LSS10999 wrote on 2024-03-31, 11:16:

but with IRQ test failing I cannot test if LDRQ1# is really working...

ehm... fyi

LPC Serial DMA/Master Request Inputs: LDRQ[1:0]# are used to request DMA or bus master access.

Those chipsets usually have two LDRQ# signals.

LDRQ0# is usually wired to SuperIO regardless of whether it's actually being used.

LDRQ1#, however, is unused in most cases. On most boards it's either routed to an unpopulated pull-up resistor (against +3V) or not exposed at all (NC).

I'm just saying that LDRQ is related to DMA, not interrupt.

weedeewee wrote on 2024-03-31, 12:47:

I'm just saying that LDRQ is related to DMA, not interrupt.

I already brought out the board's LDRQ1# with a wire and connected it to the adapter.

It's just I cannot verify whether DMA works via DIAGNOSE, because IRQ is currently not working, blocking the configuration process.

LSS10999 wrote on 2024-03-31, 12:57:

weedeewee wrote on 2024-03-31, 12:47:

I'm just saying that LDRQ is related to DMA, not interrupt.

I already brought out the board's LDRQ1# with a wire and connected it to the adapter.

It's just I cannot verify whether DMA works via DIAGNOSE, because IRQ is currently not working, blocking the configuration process.

Ah. Now I follow what you meant.

What IRQ do you setup for your soundcard? 5 or 7? Check with DMM if this irq lines goes to fintek and have no shorts to neighbour signals. Use some flux for soldering. Also are you sure that IRQs are free on your system? You can still use Hwinfo to look at IRQ allocation. In my case BIOS alloced it for onboard peripherals like USB. I have some problems with IRQ7 that was not clerarly explained, only IRQ5 works well for me but I have to reserve it by LPT that I disable after boot.

RayeR wrote on 2024-03-31, 13:00:

What IRQ do you setup for your soundcard? 5 or 7?

None of the four options available in DIAGNOSE (3, 5, 7, 10) work.

RayeR wrote on 2024-03-31, 13:00:

Check with DMM if this irq lines goes to fintek and have no shorts to neighbour signals. Use some flux for soldering.

This is my second v0.2 build, as this revision is known to be usable. I've checked the soldering with a loupe and made sure all the pins were correctly soldered.

If motherboard/software issues can be ruled out then I think I'll actually check the respective IRQ lines (IRQ5 involves RN15 while IRQ7 involves RN9).

I used a good amount of flux when soldering the Fintek bridge as well as the resistor packs. IMO the Fintek bridge is not the hardest SMD part to solder. The resistor packs are.

RayeR wrote on 2024-03-31, 13:00:

Also are you sure that IRQs are free on your system? You can still use Hwinfo to look at IRQ allocation. In my case BIOS alloced it for onboard peripherals like USB. I have some problems with IRQ7 that was not clerarly explained, only IRQ5 works well for me but I have to reserve it by LPT that I disable after boot.

The board has no LPT, and HWINFO reports IRQ5 being USED by "Hard Disk" while IRQ7 is supposedly FREE. I haven't connected any actual HDD at the moment so likely means the disk controllers.

The latest HWINFO doesn't understand my X99M Killer/3.1. It's too new. HWINFO shows only a single IRQ controller and a single DMA controller. As such, I don't think what HWINFO reports in this state is conclusive.

I know the board has a lot of onboard components, so there's a very good chance something is using those legacy IRQs. It's just I don't have a good tool to accurately tell me which devices are taking them. Outputs from Linux are not helpful as most devices are routed to insanely high interrupt numbers thanks to APIC and I could not find any good info on which IRQ number they initially take (before APIC).

You can tell linux not to use the apic with the noapic option in the linux command line. If you use grub, you can press e to edit the line just before linux boots.

EduBat wrote on 2024-03-31, 15:27:

You can tell linux not to use the apic with the noapic option in the linux command line. If you use grub, you can press e to edit the line just before linux boots.

I doubt Linux would work correctly that way... On the other hand I found a DJGPP version of lspci which might be useful.

Will also give RBPCI a try.

Still, maybe X99 is indeed too new for a good amount of DOS functionalities... FreeDOS' FDAPM doesn't work on this one. When I tried shutting down the system with FDAPM the operation failed and aborted due to ACPI errors that I currently don't understand.

OK, I don't remember if I run HWinfo on something newer that my intel P67 chipset and seen some shortened IRQ list in HWinfo.
Also my "smb /pci" gives some info about IRQs as it reads from PCI config space. You can try to disable all peripherals except IDE controller and see if it leave IRQ5 free. I'm frustrated there's no some normal way how to force BIOS PnP enumerator to change IRQs allocation...
Yes FDAPM may fail on newer system with too new ACPI version. What ACPI do you have? Gigabyte with Award hybrid BIOS was quite conservative and have old ACPI 1.0b so FDAPM works fine but with ACPI 2.0 and newer maybe problem. You can try Laaca's ACPITOOL, it should aslo have function for power off and restart:
http://laaca.borec.cz/soubory/acpitool.zip

I wonder if this really has anything to do with the BIOS PIRQ routing table.

Here are the respective register dumps (60h, 64h, 68h) I obtained from my boards.

RUBY-9719VG2AR

160: 0A0B0B0A // A: 10, B: 11, C: 11, D: 10
264: 000000D0 // SIRQ Enabled, Continuous Mode
368: 06800780 // E: -, F: 7, G: -, H: 6

X99M Killer/3.1

160: 050B0A0B // A: 11, B: 10, C: 11, D: 5
264: 00000090 // SIRQ Enabled, Quiet Mode
368: 80078003 // E: 3, F: -, G: 7, H: -

On my RUBY-9719VG2AR, I can actually reserve the IRQ I want to use (such as IRQ5) in BIOS, so its routing table avoided IRQ5 in this case.

But in case of my X99M Killer/3.1, all the IRQs in question (3, 5, 7, 10) are mentioned. This means at least 1 PCI device may be claiming those IRQs.

Not sure if I can alter the routing table at this stage (after booting to DOS) without side effects, like moving IRQ 5 or 7 to IRQ 6, since the board doesn't have a floppy drive. After all, the new board's BIOS/UEFI does not provide such options.

Maybe changing irq routing table directly in bios flashrom? But i never seen such mod by some bios hackers.

Looks like Ralf Brown's PCICFG proved to be helpful here. Was able to solve the issue with IRQ usage.

- IRQ5 was taken by the USB3 controller.
- IRQ7 was taken by the onboard audio.

Disabling the onboard audio allowed me to set IRQ7 for the sound card. However, it seems LDRQ1# I brought out is not working correctly, as DIAGNOSE currently gets stuck at DMA section, saying the DMA channels are not usable.

Maybe the wire I used is too long? On the other hand, do I need to also connect LDRQ1# to the pull-up (the other side of the resistor footprint on which LDRQ1# resides)? At present I only brought out the LDRQ1# itself.

EDIT: I did try modifying the PIRQ table from DOS. It doesn't work. The PIRQ table must be configured as early as possible... so a BIOS mod is definitely needed if I want to keep PCI devices (particularly onboard audio) away from IRQ7.

Plus, the IRQ6 (Floppy) is disabled by default per FreeDOS' "irq" tool. Can be enabled with that tool if needed. Just I don't know if it's possible to enable this on boot so as to route one of the PIRQs there.

Wiring is probably not critical, in my case I have ~10cm of wire from PCH to TPM header + ~20cm of ribbon cable to LPC2ISA PCB. In the datasheet the LDRQ# pin is described as "O24 - Output pin with 24mA source-sink capability". So it should be totem pole output with high and low drive (not an open-drain) so pullup is not necessary.

IRQ and DMA maybe linket together, if IRQ doesn't work properly, then DMA transfer fails too as no IRQ come at the end of the transfer. I don't know how exactly this IRQ/DMA tests works.