Christian Holzapfel schrieb am Montag, 2. Januar 2023 um 21:22:08 UTC+1:
> However, functional tests fail:
> - UMS applications complain about "Video adapter not found" altough seen in the device list

No wonder: The AIX kernel did recognize the device on the bus, but the driver fails initializing it. So it is there, but being disabled.

When dumping the POS registers with my tool, it shows bits 6 and 7 of POS[5] being 0, indicating "a channel check excaption is active".
So it sounds to me like the card had found an error itself, and by reporting it through the POS registers, the driver refuses to load.

The MicroChannel Architecture HITR states:

"When bits 6 and 7 in POS Register 5 are set to 0, reading POS
Registers 6 and 7 will return the channel-check-status information.
This information can be status or a pointer to the status."

Using POS extended addressing (= writing an address to POS[6-7] to read alternative data in POS[3-4]) I learned that the card only supports subaddresses 0x0000 and 0x0001, and all further addressing halts the machine. Extended POS addressing is optional and vendor defined. This is what I got:

Address POS3 POS4
POS6-POS7
0x0000 0xA5 0x01
0x0001 0x80 0x01

Without proper documentation on the vendor defined use of those fields, it looks pretty useless...

Christian Holzapfel schrieb am Donnerstag, 5. Januar 2023 um 19:30:38 UTC+1:
> Without proper documentation on the vendor defined use of those fields, it looks pretty useless...

The MIAMI spec delivers.

There are precise descriptions of the POS registers. Meanings of each bit, and how to use extended addressing through a window to access the local bus.
Quite a lot to digest...

Christian Holzapfel schrieb am Donnerstag, 5. Januar 2023 um 19:30:38 UTC+1:
> "When bits 6 and 7 in POS Register 5 are set to 0, reading POS
> Registers 6 and 7 will return the channel-check-status information.
> This information can be status or a pointer to the status."
>[..]
> Without proper documentation on the vendor defined use of those fields, it looks pretty useless...

> The MIAMI spec delivers.

Obviously the card detected a "Channel Check" condition. "Channel" seems to refer to the Microchannel only, rathern than to a local bus error.

The MIAMI spec deciphers:

"With the -CHCK enable bit set in POS, -CHCK is asserted under the following conditions:

- An exception condition is detected on the Local Bus during a slave read from the Micro Channel. This function is only supported with the CD CHRDY Timeout Disable (Bit 12, PROC_CFG) set with Timeout enabled.
- Local Bus parity is detected during a slave read from the Micro Channel. This function is only supported with the CD CHRDY Timeout Disable (Bit 12, PROC_CFG) set with Timeout enabled.
- A data parity error is detected on the Micro Channel during a slave write from the Micro Channel.
- An address parity error is detected on the Micro Channel.
- Miami asserts CD CHRDY as a Micro Channel slave for longer than three microseconds.
- An invalid byte enable combination is detect on the Micro Channel during an access of Miami as a slave.
- An extra streaming data strobe is received after Miami indicates streaming termination as a slave."

So only MCA related errors pop up here. Great. MCA and MIAMI are properly documented, contrary to the PCB's local bus design.

When a -CHCK condition occurs, further status data can be read from POS6, which reads as 0x01 in my case:

"POS 6 (Status)
BIT 7-5: Reserved. These bits are set to zero when a channel check condition occurs.
BIT 4: Basic Cycle Data Parity Error. This bit, when set, indicates that a data parity error occurred on the Micro Channel during a basic transfer cycle to Miami
BIT 3: Streaming Cycle Data Parity Error. This bit, when set, indicates that a data parity error occurred on the Micro Channel during a streaming data cycle to Miami
BIT 2: Extra Streaming Data Strobe. This bit, when set, indicates that an extra streaming data strobe was active after Miami as a slave indicated streaming terminations.
BIT 1: Channel Ready Timeout. This bit, when set, indicates that Miami as a slave has negated Micro Channel channel ready for more than three microseconds.
BIT 0: Invalid Byte Enables. This bit, when set, indicates that an invalid combination of byte enables has occurred on the Micro Channel during a transfer to Miami as a slave. This error condition is checked for both basic transfer and streaming data transfers."

Since BIT 0 is the only one set, *THIS* seems to be the specific bus error.

Sounds like SETUP transfers are running properly, but something is still wrong with the MCA's BE[3:0]# lines. Probing to the rescue!

Praytell, WHAT is the transfer from? Bus error or device error?

Firing up the popcorn popper and melting butter, this should be good...

Christian Holzapfel wrote:
> BIT 0: Invalid Byte Enables. This bit, when set, indicates that an invalid combination of byte enables has occurred on the Micro Channel during a transfer to Miami as a slave. This error condition is checked for both basic transfer and streaming data transfers."
>
> Since BIT 0 is the only one set,*THIS* seems to be the specific bus error.

Louis Ohland schrieb am Freitag, 6. Januar 2023 um 13:38:34 UTC+1:
> Praytell, WHAT is the transfer from? Bus error or device error?

"An invalid byte enable combination is detect on the Micro Channel during an access of Miami as a slave."
So I would say, a BE[3:0]# protocol error detected by the adapter (=Miami = slave).
Those lines are only being _read_ by the adapter, and set by the bus master (system board).

I couldn't probe anything wrong with those lines, and they go from the MCA edge connector right up to Miami. No glue logic involved this time.

I found one (last, I promise!) cold solder joint on the U48 that I replaced, and it was the CMD# line (-.- )
That certainly caused some randomness on the bus.
With that fixed, the Microchannel -CHCK condition is GONE!

The driver still refuses to load. Hmm...

How optional is the "M-JPEG hardware compression and decompression guest feature card"?
http://www.holzapfel.biz/8F96/UltimediaVideo7-5_GuestCard.jpg
http://www.holzapfel.biz/8F96/UltimediaVideo7-5_GuestCard_2.jpg

As it is an additional $1,500 charge listed in the announcement
https://www.ardent-tool.com/RS6000/194-326.txt
I would presume the base card *could* live without it.

So far I left the guest card off for reduced complexity.
When booting with the guest card on, kernel hangs on the 714 three-digit-display message, meaning "A video capture adapter is being configured." and it failed seriously.
At least there is something going on now on the card with the MCA bus interface - hopefully - recovered.

The guest card has a few scratches on the solder side, but all of them still beep through fine.

There is a broken line near the rework in the lower left corner, but I would assume this cut has been done intentionally - maybe with a solder tip, as it is quite round:
http://www.holzapfel.biz/8F96/UltimediaVideo7-5_GuestCard_rework.jpg
Fixing it manually didn't change a thing for the boot lock up.

So there's still trouble on the board, with and without the guest card.

I acquired another MIAMI based adapter, the FC (6219, 6222), Type 4-M, "Micro Channel SSA Multi-Initiator/RAID EL Adapter" for comparison.
It has Adapter ID 0x8697, go figure.

Turns out, MIAMI has a quite convenient (but slow, probably for engineering purposes) way of accessing all its local address space (non-bursting region: 0x00000000 - 0x1FFFFFFFF) through two 32-bit registers in the adapter's IO address space, which is easily available.

Sing a song like this for any MIAMI based adapter:

Use MIOCCGET ioctl to read the POS registers 0..7.
Use MIOCCPUT/GET ioctls to read XPOS register 3A through addressing in POS6 and POS7.
The adapter's IO base address is derived from POS5[5:3] and POS3A[7:5] (or just look it up in the ODM database). Probably 0xC000 or 0xD000.
Use MIOBUSGET/PUT ioctls to read/write MIAMI's Micro Channel accessible registers at IOBASE + 0x00..0x1F, e.g. 0xD010 to access the MDATA register. Those are only a small subset of all available registers.
Micro Channel accessible registers HSBR (IOBASE + 0x0C) and MDATA (IOBASE + 0x10) are a 32-bit wide window for accessing any address on the local bus, including the MIAMI registers themselves!
Write the local bus address you want to read to HSBR and do a read on MDATA (or write to MDATA if you dare).
There you have read a 32 bit word from the adapter's local address space.
Happy roaming!

Christian Holzapfel schrieb am Donnerstag, 12. Januar 2023 um 16:26:52 UTC+1:
> There you have read a 32 bit word from the adapter's local address space.

Using said technique allows me reading and comparing the /internal/ Miami registers of the Ultimedia Video (ID 8F96) and SSA Adapter (ID 8F97).

Reading some internal registers of the SSA shows plausible values. Reading the Card ID register returns the card ID, and register contents change with address incremented.

Reading the same registers on the Ultimedia Video returns all 0x1FFF0050 for just any address, no matter if internal or external to MIAMI.
Reading standard Micro Channel accessible registers through the IO space shows reasonable content though, also compared to the SSA.
Interestingly, 0x1FFF0050 looks like an ADDRESS inside Miami's local space itself! But it should not appear there as a VALUE.

Looks like something is wrong on Miami or it's external local address space.
How is it even possible for any external component next to Miami, like a CMOS buffer, to override Miami's /INTERNAL/ register values?
I would assume, inside Miami, the internal addresses like card ID register would be separated from the external local bus' address space.

Miami toast?

Christian Holzapfel schrieb am Donnerstag, 12. Januar 2023 um 16:37:15 UTC+1:
> Reading standard Micro Channel accessible registers through the IO space shows reasonable content though, also compared to the SSA.

So reading from and writing to Miami is *generally* fine.

When dumping the local bus space, I was hoping to see a failure pattern, like any 3rd bit high or so, and to track that trace down to a certain CMOS buffer to swap.
But not being able to dump the local space leaves me...where?
Maybe there is rather something wrong with the local bus CONTROL lines than data.
Any smart hints? What do your guts say?

Christian Holzapfel schrieb am Donnerstag, 12. Januar 2023 um 16:56:25 UTC+1:
> When dumping the local bus space, I was hoping to see a failure pattern, like any 3rd bit high or so, and to track that trace down to a certain CMOS buffer to swap.
> But not being able to dump the local space leaves me...where?
> Maybe there is rather something wrong with the local bus CONTROL lines than data.

"The Local Bus is based on the Intel 80960 Processor Bus. The Local Bus contains a 32-bit multiplexed address/data bus."

So address and data are on the same lines. If something external is holding them tight instead of letting them float.....

Miami does not set the -L_EXCPT signal, which means that data parity and integrity on the local bus are intact.

Unfortunately my spare Miami board, the SSA adapter has decided to go nuts, so I will need another board to rip the Miami off.

Also swapped a 74F74 flip flop on the board, as my only chance may be replacing components piece by piece. This was not it. Narf!