Transit Note #28

MBTA: Boot Sequence

Andre DeHon

Original Issue: July 1990

Last Updated: Wed Nov 10 22:17:45 EST 1993

Purpose

This note describes the boot sequence for an MBTA multiprocessor. This document will, no doubt, be fleshed out and become more detailed as MBTA design and construction progresses. Many of the details discussed here are described elsewhere in the documentation regarding the components to which they relate (tn20) [DeH90d] [DeH90c]. This note attempts to collect this information into a coherent whole.

Initial Configuration

One or more nodes of the MBTA multiprocessor will be connected to a T-Station host interface (tn20). When MBTA powers up should be asserted for all processors on all nodes. If there are multiple T-Station interfaces, only the master T-station will drive and (tn27). and should be asserted at power up.

Host Node Boot

The node directly connected to the T-Station interface will be the boot node. T-Station will fill the node's memory with the data the node processor needs to boot and begin processing. Node memory is filled by writing directly into the node's memory. MBTA configuration information ( e.g. number of dummy cycles, node number) should be written into the appropriate locations for the processor to find it. Once the node memory is properly loaded, T-Station will boot the node by deasserting . T-Station should watch to verify that the processor succeeded in booting.

should be deasserted at some point while the host is booting the node. It should probably be deasserted just before the processor is reset. may be deasserted at any time after the power has stabilized to all components. It must be deasserted by the time the processor attempts to configure the network interfaces.

Once the processor is running, it should go on to initialize the rest of the node. This will entail configuring the net-in (tn24) and net-out (tn23) units accordingly.

If multiple nodes are attached to T-Station interfaces, each can be loaded and booted in this manner.

Network Node Boot

Once loaded and configured, the boot node uses the network to load and boot other nodes. Using raw network read and write operations, a booted node can write the appropriate information into an unbooted node's memory. The booted node may need to coordinate with the host interface to obtain any additional data necessary for booting the unbooted node ( e.g. node specific code or data). Once the unbooted node's memory is loaded, the node booting it will send a RESET message to force the node to boot. The node sending the RESET message should wait for and check the acknowledgment from the RESET operation to be sure that the node booted successfully.

Each newly booted processor should start by initializing the rest of its node to configure the network interfaces appropriately.

The booting of nodes can fan-out in an exponential fashion. The original boot node will boot one other node. Those two nodes can then boot two others; those four can boot four others, etc. In this manner, all nodes can be booted in rounds. If we pay attention to the detailed wiring patterns in each MBTA machine, it should be possible to choose groups of nodes which can boot other groups of nodes without conflicting for network access. Such a partitioning will allow this boot sequence to occur without blocking in the network.

Network Test

Once all the nodes have been booted, a network test sequence should be run to verify the integrity of the network.

Starting Emulation

After booting all the nodes and testing the network, the boot node should verify that all nodes are ready to begin emulation. Once each node indicates it is ready to start emulation, each node except the boot node should read WAIT_EMULATE to wait for emulation to begin. Once the boot node has verified that everyone is ready to start emulation and is waiting for emulation to begin, it will inform the host interface that the MBTA machine is ready to begin emulation. The host will then deassert to begin emulation.

See Also...

References

DeH90a
Andre DeHon. MBTA: Modular Bootstrapping Transit Architecture. Transit Note 17, MIT Artificial Intelligence Laboratory, April 1990. [tn17 HTML link] [tn17 FTP link].

DeH90b
Andre DeHon. MBTA: Network Initialization. Transit Note 27, MIT Artificial Intelligence Laboratory, July 1990. [tn27 HTML link] [tn27 FTP link].

DeH90c
Andre DeHon. MBTA: Network Interface (input). Transit Note 24, MIT Artificial Intelligence Laboratory, July 1990. Obsolete; See Transit Note #31. [tn24 HTML link] [tn24 FTP link].

DeH90d
Andre DeHon. MBTA: Network Interface (output). Transit Note 23, MIT Artificial Intelligence Laboratory, July 1990. Obsolete; See Transit Note #31. [tn23 HTML link] [tn23 FTP link].

DeH90e
Andre DeHon. MBTA: Network Level Transactions. Transit Note 19, MIT Artificial Intelligence Laboratory, June 1990. [tn19 HTML link] [tn19 FTP link].

DeH90f
Andre DeHon. MBTA: Thoughts on Construction. Transit Note 18, MIT Artificial Intelligence Laboratory, June 1990. [tn18 HTML link] [tn18 FTP link].

DeH90g
Andre DeHon. T-Station: The MBTA Host Interface. Transit Note 20, MIT Artificial Intelligence Laboratory, June 1990. [tn20 HTML link] [tn20 FTP link].

DS90a
Andre DeHon and Thomas Simon. MBTA: Node Architecture. Transit Note 25, MIT Artificial Intelligence Laboratory, July 1990. [tn25 HTML link] [tn25 FTP link].

DS90b
Andre DeHon and Thomas Simon. MBTA: Node Architecture Selection. Transit Note 22, MIT Artificial Intelligence Laboratory, June 1990. [tn22 HTML link] [tn22 FTP link].

MIT Transit Project