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

SPARCserver-1000
and
SPARCserver-1000E


System

Each system-board (maximum of 4) has a single XBus, running at 40 Mhz in the SS1000 and 50MHz in the SS1000E.

The individual XBuses are linked together via the single backplane XDBus.

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

System-boards cannot be mixed between SS1000 and SS1000E systems.


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.

If you have Year2000-compliant BootPROMs (v3.21), then you already have support for all usable MBus modules.


Overheating

Although difficult, it is possible to configure an SS1000 so that it will overheat some components (MBus modules and system-board circuitry).

If you follow the configuration rules in the "SPARCserver-1000 User Guide", you will be fine. Especially:


Other Issues

Double-width MBus modules will not physically fit in slot "A" if there are DSIMMs present on that system-board. Double-width MBus modules in slot "B" will block SBus slot 1 on the same system-board.

System-boards, CPU modules (and memory DSIMMs) should always be arranged according to the "SPARCserver-1000 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
SS1000 SS1000E
CYM6001K
SM100
SM20
SM21
SM30
SM40
SM50
HMany
1 no no n/a
2
SM41
(33MHz)
501-2318
1 no no n/a
2
SM41
501-1714
501-2258
1 maybe no (2.11?)
2
SM41
501-2270
1 yes  [6] no 2.11?
2
SM41
501-2359
1 yes no 2.11?
2
SM52 1 unlikely  [2]  [4]  [5] no  
2 no no n/a
SM52X
SM520
1 unlikely  [2] unlikely  [2]  
2 no no n/a
SM521 1 unlikely  [3] unlikely  [3]  
2 no no n/a
SM51
501-2317
501-2352
501-2361
501-2607
1 maybe no (2.11)
2
SM51
501-2562
501-2360
1 yes no 2.11
2
SM51
501-2387
501-2707
1 yes yes 2.11
2
SM51
501-2617
501-2754
1 yes yes 2.18
2
SM51-2
501-2353
501-2601
1 yes  [1] no 2.11
2
SM51-2
501-2618
501-2755
1 yes  [1] no 2.18
2
SM61
501-2571
1 unlikely no (2.11)
2
SM61
501-2613
501-2772
501-2782
1 probably probably 2.11
2
SM61
501-2752
1 no no n/a
2
SM61
501-2769
1 yes no 2.18
2
SM61
501-2519
501-2825
1 yes yes 2.18
2
SM61-2 1 yes  [1] yes  [1] 2.18
2
SM71
501-2520
501-2904
501-2940
501-3001
501-4130
1 no no n/a
2
SM71
501-2925
1 yes  [4] yes  [4] 2.23
2
SM81 1 yes  [4] yes  [4] 2.23
2
SM81-2
SM91-2
1 yes  [1]  [4] yes  [1]  [4] 2.23
2

Footnotes:
1.
Only 1Mb of the 2Mb per-module cache memory is used.
2.
This module only fits in XBus slot B.
3.
This module only fits in XBus slot A.
4.
Systems manufactured before July 1995 need to be fitted with replacement side-panels 330-1869, to increase the flow of cooling air.
5.
This module runs hot enough to potentially damage the systemboard, even when the system is fitted with side-panels 330-1869. Do not use these modules without great caution and additional cooling.
6.
Only revision -04 of this module is officially supported in the SS1000. There are no known experiences with earlier revisions, unless you know otherwise...

Introduction Buses Modules Systems Chips Miscellany
Mike Spooner, revised 28th December 2001