1. Forum
  2. Usenet
  3. COMP.SYS.IBM.PS2.HARDWARE

  • Monitoring MCA and PCI I/O window

    From Louis Ohland@21:1/5 to Christian Holzapfel on Tue Oct 24 07:28:36 2023
    Hope dies last...

    How can you monitor accesses to the I/O window on the MCA side and the
    PCI side? If it is a SIMMple use of an I/O window, maybe we can
    turbo-diddle the conversion?

    Dammit Jim, I'm a doctor, not an engineer...

    Christian Holzapfel wrote:
    I'm afraid, we're on the wrong track here, and said patent does not have anything to do with our 9-K adapter.
    It must be using a completely different way of configuration, maybe through the IO window.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christian Holzapfel@21:1/5 to Louis Ohland on Tue Oct 24 08:17:40 2023
    Louis Ohland schrieb am Dienstag, 24. Oktober 2023 um 14:28:33 UTC+2:
    How can you monitor accesses to the I/O window on the MCA side and the
    PCI side? If it is a SIMMple use of an I/O window, maybe we can
    turbo-diddle the conversion?

    It's certainly doable.
    One could probably build an address decoder for the 0x1CXX IO range out of A[8-15] and M/IO# with some fast discrete 74xx logic or an FPGA to retrieve a trigger signal whenever the card's IO range is addressed. I've never done that so far.
    Then one would need to monitor A[0-5] to capture the address inside the window that is actually written to, plus the D[0-31] lines. Way too many channels for my cheap analyzer.
    Maybe we're lucky and the driver does 8-bit wide access only, then my tools would be sufficient. But for an 32-bit OS driving a 32-bit card on a 32-bit bus, I doubt it for now.
    Maybe there's a smarter way.

    Since all this "probably" happens during AIX driver initialization, I'm not sure the kernel debugger would be of great help, if I understand it at all.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ryan Alswede@21:1/5 to All on Wed Nov 8 19:11:43 2023
    Christian Holzapfel through his work has discovered the io window addressing that the ASIC uses to talked to the Pcnet chipset. We now know how the the PCI config registers are set on the PCI bus, how VPN data is read from the base card and some
    readings on card init / IRQ reset.

    The patent pdf on the 9-K page is not related to this card and should be removed from the 9-K page.

    I've emailed Tomáš Slavotínek the official ADF file. Driver development is underway and more info will be released in time.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Louis Ohland@21:1/5 to Louis Ohland on Thu Nov 9 08:08:21 2023
    My dark suspicion is since the 9-K was only used under AIX, the O/S
    handled the hardware WITHOUT needing to go the Sub POS route.

    Louis Ohland wrote:
    Ryan Alswede wrote:
    Christian Holzapfel through his work has discovered the io window
    addressing that the ASIC uses to talked to the Pcnet chipset.  We now
    know how the the PCI config registers are set on the PCI bus, how VPN
    data is read from the base card and some readings on card init / IRQ
    reset.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Louis Ohland@21:1/5 to Ryan Alswede on Thu Nov 9 08:04:36 2023
    One yard and a cloud of dust.

    The patent pdf on the 9-K page is not related to this card

    We use what we got until someone proves it otherwise. I'm happy to be
    proven wrong, since the Magic Christian has penetrated the inner sanctum
    of IBM secrecy....

    https://www.youtube.com/watch?v=EYOaNOLVMb0

    Any SWAG on which card? Which type of card? Components which would be significant to that style of Sub POS implementation?

    Ryan Alswede wrote:
    Christian Holzapfel through his work has discovered the io window addressing that the ASIC uses to talked to the Pcnet chipset. We now know how the the PCI config registers are set on the PCI bus, how VPN data is read from the base card and some
    readings on card init / IRQ reset.

    The patent pdf on the 9-K page is not related to this card and should be removed from the 9-K page.

    I've emailed Tomáš Slavotínek the official ADF file. Driver development is underway and more info will be released in time.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ryan Alswede@21:1/5 to All on Thu Nov 9 07:06:47 2023
    WITHOUT needing to go the Sub POS route.

    Louis it's very very good news. I/O can be done easily from a device driver since that's what a device driver does all day long.

    AIX OS isn't needed to use this card. And we don't have to try to figure out assembly for an init POS program.

    I'll let Christian share his Linux driver progress when he is ready.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Louis Ohland@21:1/5 to Ryan Alswede on Thu Nov 9 10:25:35 2023
    My thought was NOT that we needed AIX, but perhaps the adapter didn't
    use Sub POS because AIX spoke directly to the card registers or
    whatever. I _think_ adapters can be initialized both via ADF / IADF -or-
    Sub POS.

    I'm not broke up over not needing AIX...

    Ryan Alswede wrote:
    AIX OS isn't needed to use this card.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christian Holzapfel@21:1/5 to All on Thu Nov 9 09:44:46 2023
    Yes, it's true!

    Finally there is a Linux driver for the card that you can try on your dusted 2.2 kernel:

    https://github.com/holzachr/sanremo-linux

    Getting there was quite a ride.

    Using cheap clones of usually expensive 8- and 16-channel USB logic analyzers, I initially sniffed on the CDSETUP# line of the card, plus A0-2 and D0-7, to see all accesses to the POS registers during card initialization on my RS/6000 7006-42T with AIX 4.
    3.3.
    That did not show up anything significant, but experimenting with multiple card and seeing the POS values set according to the assigned ressources led us to conclusions that Ryan welded his ADF from.

    Now knowing that the card is not *mainly* set up through the POS registers, we concluded it must go through the regular I/O port window at 0x1C00 to 0x1FFF.
    From some discrete 74xx logic I built a simple address decoder that gave me a single trigger once the 0x1Cxx range is addressed.

    Check out the nifty setup:

    http://www.holzapfel.biz/8F62/LogicAnalyzers.jpg

    Further, I used a Snark Barker as a bus break-out board (yes, in an RS/6000!), since it has unpopulated pin headers for many important bus signals.
    Being an 8-bit card only, I had to tap in on the San Remo card to get the upper Data and -BE lines.

    Having that compact many-in-one trigger signal, I was able to capture the initalization sequences on the Micro Channel bus when the card is initialized.
    Trigger + CMD# + S0WRITE# + S1READ# + A0-7 + Data0-31 + BE0-3.
    Although the initialization sequence is always the same, this led to countless hours of digital signal analysis and writing down what I/O addresses are accessed, read or written, and which data is exchanged.
    Living the dream.

    With everything written down in endless lists, Ryan and I were able to see patterns in those accesses and data, bit by bit, concluding what those ASIC I/O registers do, how data is tunneled through the ASIC to the PCnet chip and how interrupts are
    handled.

    Finally, I was able to modify the existing PCnet32 Linux driver to work with the card in my PC 750.

    Let's see if someone is able to form a Windows 9X/NT driver from that...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)