The Rough Guide to MBus Modules
Introduction Buses Modules Systems Chips Miscellany

SPARCcenter-2000
and
SPARCcenter-2000E

System

Each CPU/memory board (maximum of 10) has a pair of XBus slots.

Each system-board plugs into both backplane XDBuses.

Each system-board provides two opposed slots for MBus modules: slot "A" is nearest the front of the chassis (by the XDBus backplane connectors), slot "B" is nearest the back (by the SBus slots).

The XBus/XDBuses run at 50MHz in the SC2000E, and at either 40MHz or 33MHz in the "plain old" SC2000, depending on the exact System Control Board fitted.

Very early SC2000 systems (1992) have System Control Board 501-1671-04 (and not any later rev of that part), which runs at 66MHz itself, but clocks the XBus/XDBuses at 33MHz. Other non-E SC2000 System Control Boards run at 40MHz, and clock the XBus/XDBuses at 40MHz.

Presumably, you can upgrade an SC2000 to an SC2000E by replacing the System Control Board and all the CPU/memory boards...?

Firmware Versions

Older systems may require BootPROM upgrades to be able to use newer MBus modules. Where known, the minimum BootPROM level is listed in the module configuration table.

Overheating

I would expect that it is extremely difficult to to configure an SC2000 so that it would overheat some components (MBus modules and system-board circuitry).

If you follow the configuration rules in the "SPARCcenter-2000 User Guide" and "SPARCcenter-2000 Site Preparation Guide", you will be fine. Particularly:

Other Issues

Double-width MBus modules may not physically fit, or may obstruct DSIMM slots or SBus slots. I do not know the layout of the system-boards well enough to guess.

CPU/memory boards, CPU modules, and memory DSIMMs should always be arranged according to the "SPARCcenter-2000 User Guide". To allow the system to properly automatically disable failed system-boards and CPU modules, you must:

  1. Fill the backplane slots from the top downwards, with either system-boards or disk-trays.

  2. Starting with the top-most system-board, populate all the "A" CPU slots across all system-boards before filling any of the "B" slots.

  3. Have all system-boards fitted with the same level of BootPROM.
The reason is due to the way that a master system-board is dynamically selected during boot: the top-most working system-board that contains a working CPU number 0 (in slot "A") is selected as the master. Next, that master system-board disables all failed system-boards and failed CPU modules and failed DSIMM groups (on all system-boards), and downloads it's BootPROM firmware into "BootRAM" on all the remaining enabled system-boards. Finally, CPU number 0 on the master system-board bootstraps the operating-system.

Failure to follow the above rules may result in operating-system crashes, if a module or system-board fails, due to older BootPROM code (from a surviving system-board) being used. Such failed components may also render the system unbootable (if all your DSIMMs or "slot-A" CPU modules are on failed system board(s), the surviving system-boards will not have the resources needed to boot the operating-system).

It is possible that dual-CPU MBus modules may defeat the boot-time automatic deconfiguration of failed components. For instance, there is a strong possibility that the BootPROM may neglect to disable a CPU module that has both a working CPU and a failed one, because it may not be expecting a second CPU on the module.

There is also the possibility that the PROM would neglect to initialise more than one CPU per module... ie: dual-CPU modules might behave as single-CPU modules, or even not work at all.

MBus Module Configuration Table

Specific part-numbers are only listed where significant.

See also: General Module Configuration Rules, which also covers mixed-module configurations.

Note: some configurations have particular caveats, such as failing to provide the level of performance that one might intuitively expect, or dangerous overheating, and so on. Such configurations are marked with a footnote-number in square brackets.

Module Type No. of
(identical)
Modules per
system-
board		 Functional? Min. PROM level
SC2000 (33MHz XBus) SC2000 (40MHz XBus) SC2000E
CYM6001K
SM100
SM20
SM21
SM30
SM40
SM50
HMany		 1 no no no n/a
2
SM41
(33MHz)
501-2318
1 yes no no 2.10?
2
SM41
501-1714
501-2258
1 maybe maybe no (2.11?)
2
SM41
501-2270
1 probably  [4] yes  [4] no 2.11?
2
SM41
501-2359
1 yes yes no 2.11?
2
SM52 1 very unlikely  [2]  [3] very unlikely  [2]  [3] no  
2 no no no n/a
SM52X
SM520		 1 very unlikely  [2] very unlikely  [2] unlikely  [2]  
2 no no no n/a
SM521 1 very unlikely  [2] very unlikely  [2] unlikely  [2]  
2 no no no n/a
SM51
501-2317
501-2352
501-2361
501-2607
1 maybe maybe no (2.11)
2
SM51
501-2562
501-2360
1 probably yes no 2.11
2
SM51
501-2387
501-2707
1 probably yes yes 2.11
2
SM51
501-2617
501-2754
1 very probably yes yes 2.18
2
SM51-2
501-2353
501-2601
1 probably  [1] yes  [1] no 2.11
2
SM51-2
501-2618
501-2755
1 probably  [1] yes  [1] no 2.18
2
SM61
501-2571
1 unlikely unlikely no (2.11)
2
SM61
501-2613
501-2772
501-2782
1 probably probably probably 2.11
2
SM61
501-2752
1 no no no n/a
2
SM61
501-2769
1 probably yes no 2.18
2
SM61
501-2519
501-2825
1 yes yes yes 2.18
2
SM61-2 1 probably  [1] yes  [1] yes  [1] 2.18
2
SM71
501-2520
501-2904
501-2940
501-3001
501-4130
1 no no no n/a
2
SM71
501-2925
1 yes yes yes 2.23
2
SM81 1 maybe yes yes 2.23
2
SM81-2
SM91-2		 1 maybe  [1] yes  [1] yes  [1] 2.23
2

Footnotes:
1.
CPU/memory board 501-1866 can only utilise 1Mb of the 2Mb per-module level 2 cache.
2.
Module may not fit, or may fit with caveats. See Other Issues.
3.
This module runs hot enough to potentially damage the CPU/memory board. Do not even consider experimenting with these modules without great caution and additional cooling.
4.
Only revision -04 of this module is officially supported in the various SC2000 systems. There are no known experiences with earlier revisions, unless you know otherwise...
Introduction Buses Modules Systems Chips Miscellany
Mike Spooner, revised 28th December 2001