On Monday, December 22, 1997 at 9:00:00 AM UTC+1, Peterwendt wrote:

Hi !
You need to know it exactly, right ? Think so.
Now here's a list that makes it easier to look in 95s underwear during boot :-)
Checkpoints
The following Stage 1 checkpoints are output to the async port only
cp Description
0110 Check processor
0120 Rom checksum
0130 Check power on values for memory controller registers
0140 Check local registers on processor card
0150 Check JTAG device ID and static capture
0160 Check L2 cache
0170 Check L1 cache
0180 Check memory controller registers
0181 Test memory address bus on processor card
0190 Check power on values for DMA controller registers
0191 Check DMA controller registers
0192 Initialize DMA controller static capture
0193 Test DMA transfers
0210 Check BIU controller registers capture
0220 Verify JTAG cycle capture on LEPB
0230 Verify error detection and enable detection for parity errors
0240 Verify ECC logic of the Memory Controller and Memory Data Bus Buffers 0250 Verify DMA transfer
0260 L1 cache snoop test
0270 L2 cache snoop test

Well, this would have been bloody useful to have some 2 years ago...

I don't have time to dive into this now but I can tell that the list is outdated (much like the list of 2-digit CP codes for the premium PS/2s). Many of these SDL CP codes are not used by the shipped T4 firmware builds, and on the other hand, some codes
that are used are missing from this list.

Anyway, looks like I got most of it right: https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

It's really helpful to know that the two remaining CPs (0150/0220) are related to JTAG. Some of the associated code certainly looked like a serial comms to me, but the complexity of the code was rather discouraging and I have mostly ignored it thus far.
But now we know that ports E6/E7h are JTAG. I wonder what kind of tests are they running there. JTAG is available on the CPU, cache controller, SRAMs, and the debug connector. I wonder if the SSC ASIC has it as well... will have to probulate when things
get less hectic on my end.

(eh, this my first post through the Google Groups iface, hopefully It makes it through unmangled)

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

On 25.08.2022 10:42, Tomas Slavotinek wrote:

Anyway, looks like I got most of it right: https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

I'll update the page later.

I wonder I about the source of this info. It's not in any of the
references we have. Time to ping Peter I guess...

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

https://ardent-tool.com/complex/T4.html#Address_Mux

The primary chip used in this implementation only requires 39 bits of
data in the ECC mode, 32 data bits and 7 check bits. Therefore, the only support required for DQ39 in this implementation is to tri-state the multiplexed logic outputs when a 40 bit ECC memory module is being
addressed. This prevents contention at the DRAM's output on DQ39.

Tomas Slavotinek wrote:

On 25.08.2022 10:42, Tomas Slavotinek wrote:

Anyway, looks like I got most of it right:
https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

I'll update the page later.

I wonder I about the source of this info. It's not in any of the
references we have. Time to ping Peter I guess...

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

Unrelated, but yes. We have talked about this before - pretty much all
ECC SIMMs are 40-bit wide internally, even if the algorithm requires
only 39-bits.

Some modules have all 40 bits exposed on the pins, but the special Model
90/95 16 and 32MB ECC SIMMs don't. This is because IBM had to redefine
some of the pins to squeeze in the additional address lines that are
missing from the "set in stone" processor complex interface (and
planars). The lines are then multiplexed on the processor complex side
and the muxing is activated or deactivated based on the SIMM ID - ECC
SIMMs with lower capacity use the standard IBM ECC pinout and are marked
as 40-bit bit wide. This how they got 16/32MB modules working with the
existing complex interface and the "old" 8590/8595 planars.

Yes yes, I know, I have promised a write up about this long time ago.
Meh, one day...

On 25.08.2022 13:46, Louis Ohland wrote:

https://ardent-tool.com/complex/T4.html#Address_Mux

The primary chip used in this implementation only requires 39 bits of
data in the ECC mode, 32 data bits and 7 check bits. Therefore, the only support required for DQ39 in this implementation is to tri-state the multiplexed logic outputs when a 40 bit ECC memory module is being
addressed. This prevents contention at the DRAM's output on DQ39.

Tomas Slavotinek wrote:

On 25.08.2022 10:42, Tomas Slavotinek wrote:

Anyway, looks like I got most of it right:
https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

I'll update the page later.

I wonder I about the source of this info. It's not in any of the
references we have. Time to ping Peter I guess...

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

Peter doesn't recall where it came from, but I don't blame him... this
was 25 years ago. Oof!

Anyway, iirc some of the listed SDL CP codes that don't exist in the T4
POST code are used in the T3 codebase... (yes, the T3 complex has a
serial diagnostic link too, but the implementation is different and the
header is not populated on production boards).

I'll check how closely it matches the T3 POST code base when I get back
to the firmware shenanigans.

On 25.08.2022 10:48, Tomas Slavotinek wrote:

On 25.08.2022 10:42, Tomas Slavotinek wrote:

Anyway, looks like I got most of it right:
https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

I'll update the page later.

I wonder I about the source of this info. It's not in any of the
references we have. Time to ping Peter I guess...

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

Expanded and moved to a separate page: https://ardent-tool.com/trouble/cp_codes_sdl.html

I can also confirm that the SynchroStream chip has a JTAG interface. It
doesn't appear to be on the same chain with the CPU or the C5/C8 cache
set - at least not on the "N" complex.

No time to probe the Type 3 complex, but it probably has a JTAG chain
between all the major chips. That would explain the significantly larger
JTAG data set in the T3 ROM.

On 25.08.2022 16:19, Tomas Slavotinek wrote:

Peter doesn't recall where it came from, but I don't blame him... this
was 25 years ago. Oof!

Anyway, iirc some of the listed SDL CP codes that don't exist in the T4
POST code are used in the T3 codebase... (yes, the T3 complex has a
serial diagnostic link too, but the implementation is different and the header is not populated on production boards).

I'll check how closely it matches the T3 POST code base when I get back
to the firmware shenanigans.

On 25.08.2022 10:48, Tomas Slavotinek wrote:

On 25.08.2022 10:42, Tomas Slavotinek wrote:

Anyway, looks like I got most of it right:
https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

I'll update the page later.

I wonder I about the source of this info. It's not in any of the
references we have. Time to ping Peter I guess...

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

All this also reminded me of the AMD K6 experiment I've done some time
ago. It failed on one of the tests that were now identified to use the
JTAG interface.

I don't have the code fully reversed but looks like they are doing an
awful lot of bitbanging there. TCK is pulsed from the code with no
explicit SW delay. So, now I wonder whether there really was a critical communication failure on the local/system bus or if this was just a
timing issue on the JTAG bus because of the CPU's ability to execute the
loops significantly faster... (sure, we are limited by the timing of the
local and system buses - 60/66 and 40 MHz, but JTAG from this era is
usually clocked even lower - 10-20 MHz maybe? The TCK signal goes
through a PAL, so it's possible that they are doing some synchronization
there, but idk... will have to probulate it with a logic analyzer.

But don't get your hopes up. It's quite likely that there will be more
problems down the road with the K6 if we push it past the JTAG tests.
But it makes me curious. I'll definitely revisit this at some point and
try bypassing the tests...

On 30.08.2022 2:09, Tomas Slavotinek wrote:

Expanded and moved to a separate page: https://ardent-tool.com/trouble/cp_codes_sdl.html

I can also confirm that the SynchroStream chip has a JTAG interface. It doesn't appear to be on the same chain with the CPU or the C5/C8 cache
set - at least not on the "N" complex.

No time to probe the Type 3 complex, but it probably has a JTAG chain
between all the major chips. That would explain the significantly larger
JTAG data set in the T3 ROM.

On 25.08.2022 16:19, Tomas Slavotinek wrote:

Peter doesn't recall where it came from, but I don't blame him... this
was 25 years ago. Oof!

Anyway, iirc some of the listed SDL CP codes that don't exist in the
T4 POST code are used in the T3 codebase... (yes, the T3 complex has a
serial diagnostic link too, but the implementation is different and
the header is not populated on production boards).

I'll check how closely it matches the T3 POST code base when I get
back to the firmware shenanigans.

On 25.08.2022 10:48, Tomas Slavotinek wrote:

On 25.08.2022 10:42, Tomas Slavotinek wrote:

Anyway, looks like I got most of it right:
https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

I'll update the page later.

I wonder I about the source of this info. It's not in any of the
references we have. Time to ping Peter I guess...

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

On Monday, August 29, 2022 at 5:18:46 PM UTC-7, Tomas Slavotinek wrote:

All this also reminded me of the AMD K6 experiment I've done some time
ago. It failed on one of the tests that were now identified to use the
JTAG interface.

I don't have the code fully reversed but looks like they are doing an
awful lot of bitbanging there. TCK is pulsed from the code with no
explicit SW delay. So, now I wonder whether there really was a critical communication failure on the local/system bus or if this was just a
timing issue on the JTAG bus because of the CPU's ability to execute the loops significantly faster... (sure, we are limited by the timing of the local and system buses - 60/66 and 40 MHz, but JTAG from this era is
usually clocked even lower - 10-20 MHz maybe? The TCK signal goes
through a PAL, so it's possible that they are doing some synchronization there, but idk... will have to probulate it with a logic analyzer.

But don't get your hopes up. It's quite likely that there will be more problems down the road with the K6 if we push it past the JTAG tests.
But it makes me curious. I'll definitely revisit this at some point and
try bypassing the tests...
On 30.08.2022 2:09, Tomas Slavotinek wrote:

Expanded and moved to a separate page: https://ardent-tool.com/trouble/cp_codes_sdl.html

I can also confirm that the SynchroStream chip has a JTAG interface. It doesn't appear to be on the same chain with the CPU or the C5/C8 cache
set - at least not on the "N" complex.

No time to probe the Type 3 complex, but it probably has a JTAG chain between all the major chips. That would explain the significantly larger JTAG data set in the T3 ROM.

On 25.08.2022 16:19, Tomas Slavotinek wrote:

Peter doesn't recall where it came from, but I don't blame him... this
was 25 years ago. Oof!

Anyway, iirc some of the listed SDL CP codes that don't exist in the
T4 POST code are used in the T3 codebase... (yes, the T3 complex has a
serial diagnostic link too, but the implementation is different and
the header is not populated on production boards).

I'll check how closely it matches the T3 POST code base when I get
back to the firmware shenanigans.

On 25.08.2022 10:48, Tomas Slavotinek wrote:

On 25.08.2022 10:42, Tomas Slavotinek wrote:

Anyway, looks like I got most of it right:
https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

I'll update the page later.

I wonder I about the source of this info. It's not in any of the
references we have. Time to ping Peter I guess...

Tomas,

Which K6 did you try? I've been meaning to test out an Evergreen Spectra I recently acquired on one of my Ys. I was hopeful that since it offloaded the power to a separate connector that it wouldn't require the same level of modifications that the
Overdrives do.

-Shane

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

On 30.08.2022 22:44, Shane Benting wrote:

On Monday, August 29, 2022 at 5:18:46 PM UTC-7, Tomas Slavotinek wrote:

All this also reminded me of the AMD K6 experiment I've done some time
ago. It failed on one of the tests that were now identified to use the
JTAG interface.

I don't have the code fully reversed but looks like they are doing an
awful lot of bitbanging there. TCK is pulsed from the code with no
explicit SW delay. So, now I wonder whether there really was a critical
communication failure on the local/system bus or if this was just a
timing issue on the JTAG bus because of the CPU's ability to execute the
loops significantly faster... (sure, we are limited by the timing of the
local and system buses - 60/66 and 40 MHz, but JTAG from this era is
usually clocked even lower - 10-20 MHz maybe? The TCK signal goes
through a PAL, so it's possible that they are doing some synchronization
there, but idk... will have to probulate it with a logic analyzer.

But don't get your hopes up. It's quite likely that there will be more
problems down the road with the K6 if we push it past the JTAG tests.
But it makes me curious. I'll definitely revisit this at some point and
try bypassing the tests...

Tomas,

Which K6 did you try? I've been meaning to test out an Evergreen Spectra I recently acquired on one of my Ys. I was hopeful that since it offloaded the power to a separate connector that it wouldn't require the same level of modifications that the

Overdrives do.

-Shane

I believe it was a regular K6-266 (non -II/-III) with the PowerLeap
PL-ProMMX Plus interposer (v4.0 IIRC). This interposer (and the mounted
CPU) is also powered directly from the PSU and has a local switching
regulator. It takes care of the clock multiplier pins too, so no bodge
wires are needed. The Evergreen one should be similar in this aspect.

There are however other problems with the later Socket 5/7 CPUs.

The non-MMX P54C Pentium chips had 3.3V I/O and core, but the clock
input was still 5 V-tolerant (to make board conversion easier/cheaper).
So, to nobody's surprise, the "Y" platform uses IBM's own 5 V clock
driver - the same one as on the "P" and "Q" boards. The clock signal
goes directly to the CPU (unlike the other non-C5/C8 input signals that
*ARE* level-shifted on "Y"). Pentium MMX (P55C) not only introduced the
split voltage design but also dropped support for the legacy 5 V clock.
Most interposers probably don't level-shift the clock. This won't damage
the chip, despite it being beyond the absolute maximum voltage, but it
may compromise the clock integrity.

Further, the P5 and P54C chips can be configured to a C5/C8 mode (the
cache chipset used on all T4 complexes). This modifies the driving
capability of certain pins IIRC. At least some of the P55C MMX chips
still have this capability, but most if not all of them were not tested
in this configuration by Intel. That's another potential problem...

The former issue is fixable, and if that's what causes the incompatibility/instability with some faster CPUs, then we should be
able to get them working.

The latter may be more difficult to solve... but I'll have to go over
the manuals again to see what exactly the C5/C8 mode modifies.

Later Socket 5/7 CPUs were designed with the "modern" PCI chipsets in
mind, so there very well may be other incompatibilities too (tighter
timings, etc.).

I plan to do more CPU experiments but first I wanna understand the T4 architecture better - down to a component level including the 74xx glue.
I'm almost there, but not quite... And the JTAG discovery will help me
crack the few remaining early POST bits too. (I had to delay all this
exciting stuff because of other more important things..)

The C5/C8 cache set is actually relatively fast - especially for its
time. But you can fit only so much into 256K. We are ultimately limited
by the relatively slow RAM subsystem (interleaved 64-bit 70 ns non-EDO)
and slow I/O bus (Micro Channel) where the best we can do is <40 MB/s sequential from/to the complex - comparable to early PCI implementations (Neptune). So at some point, the benefits of a fast CPU core flatten out
in practical applications, as it has to spend a lot of time waiting for data/instructions... The fast internal L2 cache of the K6-III(+) chips
might mask the memory bottleneck a bit, but it's still only 256K...

Anyway, please let us know how your experiments go. It's always good to
have more data!

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

On 30.08.2022 23:55, Tomas Slavotinek wrote:

Further, the P5 and P54C chips can be configured to a C5/C8 mode (the
cache chipset used on all T4 complexes). This modifies the driving
capability of certain pins IIRC. At least some of the P55C MMX chips
still have this capability, but most if not all of them were not tested
in this configuration by Intel. That's another potential problem...

I've added some basic info on the C5/C8 chipset here: https://ardent-tool.com/complex/T4.html#C5C8

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

On 8/31/22 04:17, Tomas Slavotinek wrote:

On 30.08.2022 23:55, Tomas Slavotinek wrote:

Further, the P5 and P54C chips can be configured to a C5/C8 mode (the
cache chipset used on all T4 complexes). This modifies the driving
capability of certain pins IIRC. At least some of the P55C MMX chips
still have this capability, but most if not all of them were not
tested in this configuration by Intel. That's another potential
problem...

I've added some basic info on the C5/C8 chipset here: https://ardent-tool.com/complex/T4.html#C5C8

A random thought since you are looking in these directions.. The P54 is supposed to be a glueless SMP https://www.youtube.com/watch?v=-VkFyGPiy7E&list=PLQsxaNhYv8daltwYEVnbMdaJ35YFg-6vv&index=8

I wonder if this could be finagled onto single socket carrier with a
crazy interposer. I guess the hard part would be bringing the AP
online, not sure if that could be done after POST or would require major
BIOS rework.

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

On 02.09.2022 19:12, Kevin Bowling wrote:

A random thought since you are looking in these directions.. The P54 is supposed to be a glueless SMP https://www.youtube.com/watch?v=-VkFyGPiy7E&list=PLQsxaNhYv8daltwYEVnbMdaJ35YFg-6vv&index=8

I wonder if this could be finagled onto single socket carrier with a
crazy interposer.  I guess the hard part would be bringing the AP
online, not sure if that could be done after POST or would require major
BIOS rework.

Yes, the P54C indeed supports "glueless" two-way SMP. But retrofitting
it into an existing design is not as simple as adding a dual-socket
interposer. The "glueless" aspect of it really only applies to new designs.

My main worry here are the hardware interrupts. The P54C has a local
APIC but we also need an I/O APIC on the expansion bus (Micro Channel).
All PS/2s, of course, have a PIC, but one that is not SMP-ready (APIC).
It would have no way of telling which of the two CPUs should a
particular interrupt be directed to, as there is only one interrupt line
(INTR) between the PIC and the CPU. To make things worse, in the Model
90/95 machines, the interrupt controller is part of the I/O chip on the
planar (either 85F0464 or 10G4672), and the single INTR line is part of
the "set in stone" processor complex interface.

With new designs, you simply connect the three-wire P54 APIC interface
to a compatible I/O APIC, and that's it...

I don't remember how exactly the different local APIC modes work in the
P54C, but we would probably need some sort of interrupt vectoring unit
on the complex/interposer to extend the functionality of the legacy PIC.

IBM was toying with the idea in the 486/early Pentium days: https://ardent-tool.com/docs/patent/US5381541.pdf

With the P54C CPUs, none of the local bus buffers would be needed, and
the same is true for the CPU arbitration logic. This makes things
significantly easier, but a modified version of the "multiprocessor
interrupt director" would be needed to handle the vectoring and to
interface with the three-wire APIC bus.

There may be some other issues too, but this is probably the most
significant one...

I'll read through the Pentium manuals again when I have time... so far
I've been ignoring the SMP-related chapters for the most part.

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

On 03.09.2022 19:12, Tomas Slavotinek wrote:

I'll read through the Pentium manuals again when I have time... so far
I've been ignoring the SMP-related chapters for the most part.

Just scrolled through the Pentium dev manual real quick... Figure 19-5
on page 403 physical illustrates the APIC configuration rather well:

https://ardent-tool.com/CPU/docs/Intel/Pentium/241428-004.pdf#page=403

The I/O ASIC on the planar essentially contains a dual 8259 PIC and the individual IRQ lines from MCA and planar devices are wired directly to
it... We don't have access to these IRQ lines on the complex, only to
the INTR line from the PIC. Hence the need for the "multiprocessor
interrupt director" - to take care of what the I/O APIC would normally do.

At least that's how I see things without a deep dive into the documentation.

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

On 30.08.2022 23:55, Tomas Slavotinek wrote:

Pentium MMX (P55C) not only introduced the split voltage design but also dropped support for the legacy 5 V clock. Most interposers probably
don't level-shift the clock. This won't damage the chip, despite it
being beyond the absolute maximum voltage, but it may compromise the
clock integrity.

Hmm, maybe some interposers actually take care of the clock level-shifting: https://patents.google.com/patent/US5938769
Though the proposed method with a simple resistor to ground is far from
ideal. It may cause more trouble then good...

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

https://patents.google.com/patent/US5938769

Is this the shift?

In accordance with still a further aspect of the present invention, the
CPU escalating adapter with multivoltage and multiple frequency
selection further includes a programmable array logic (PAL) for
converting a part of control signals of the CPU.

U2 GAL16V8

Inputs (I think)
ADS*
BA20M*
HRESET
HA20
HINIT
M/IO*

Outputs
F0-7
F8 TA20M*

Pin numbers don't seem to make sense.


Tomas Slavotinek wrote:

On 30.08.2022 23:55, Tomas Slavotinek wrote:

Pentium MMX (P55C) not only introduced the split voltage design but
also dropped support for the legacy 5 V clock. Most interposers
probably don't level-shift the clock. This won't damage the chip,
despite it being beyond the absolute maximum voltage, but it may
compromise the clock integrity.

Hmm, maybe some interposers actually take care of the clock level-shifting: https://patents.google.com/patent/US5938769
Though the proposed method with a simple resistor to ground is far from ideal. It may cause more trouble then good...

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

On 10.09.2022 18:50, Louis Ohland wrote:

https://patents.google.com/patent/US5938769

Is this the shift?

In accordance with still a further aspect of the present invention, the
CPU escalating adapter with multivoltage and multiple frequency
selection further includes a programmable array logic (PAL) for
converting a part of control signals of the CPU.

U2 GAL16V8

Inputs (I think)
ADS*
BA20M*
HRESET
HA20
HINIT
M/IO*

Outputs
F0-7
F8 TA20M*

Pin numbers don't seem to make sense.

No, and I'm not sure what are they doing with the PAL. They take ADS,
BA20M, HRESET, HA20, HINIT, M/IO and use them to generate a modified
TA20M signal for the CPU. They must be working around some change or
errata. Not sure. (A20 is the line that enables the legacy
8086-compatible wraparound at 1 MB.)

I0-I9 are indeed inputs. F0-F7 are I/O pins and can be configured as one
or the other (they are using only F7 - as the only output).

The "level-shifting" I was referring to (if you can call it that) is implemented using the 23K resistor R4 and can be enabled/disabled using
SW1-P4. It's more like loading the clock line down, which seems like a
really bad idea. Tbh, I don't know if the schematic is even right. The
value of the resistor makes me think that it was supposed to be part of
the LP2951 voltage set circuit. Or maybe they just decided to reuse a
resistor network they already had on the board.

The description says: "A fourth Switch of the toggle Switch member 70 is connected with a clock pin CLK of the CPU 80 for setting the clock power
of the CPU".

And in the Fig. 4 table: "CLK Vcc SW1:P4" "5V" and "3.3V"

But the function seems inverted.

Idk. But looks like they at least considered tweaking the CLK level at
some point. The actual interposer may be doing things the right way...
or not at all. Will have to probulate it.

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

Delay line? Ringing?

Tomas Slavotinek wrote:

It's more like loading the clock line down

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

P54C
P55C
M2
K6
K5
CYRIX 6×86 or 6×86L

Tomas Slavotinek wrote:

TA20M signal

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