How was the multiprocessor system bootstrapped?
Changes were required to the M9312 boot ROM. This was reportedly the hardest part of the project to figure out. In those days boot ROMs were very small, and it was difficult to figure out how to get a CPU up from a completely unknown state. What was done used the interprocessor interrupt mechanism. The IIST forced a power failure on the CPU coming on line. The boot ROM then enabled interrupts on the IIST, created a very small stack, and looped for about six seconds. During that time, the other CPUs broadcast an interrupt to it, which got it out of the boot ROM, into the Executive, and things went from there. A result of this was that only one manual boot was needed to get the system up, and the rest was achieved with reconfiguration commands, e.g. “CON ONLINE CPC”. The BOOt and SAVe components of M-Plus were modified so that they didn’t have to run on a particular CPU, and didn’t know anything about which console was which. Source: The Big Book of RSX Applications, Volume II, Appendix
Changes were required to the M9312 boot ROM. This was reportedly the hardest part of the project to figure out. In those days boot ROMs were very small, and it was difficult to figure out how to get a CPU up from a completely unknown state. What was done used the interprocessor interrupt mechanism. The IIST forced a power failure on the CPU coming on line. The boot ROM then enabled interrupts on the IIST, created a very small stack, and looped for about six seconds. During that time, the other CPUs broadcast an interrupt to it, which got it out of the boot ROM, into the Executive, and things went from there. A result of this was that only one manual boot was needed to get the system up, and the rest was achieved with reconfiguration commands, e.g. “CON ONLINE CPC”. The BOOt and SAVe components of M-Plus were modified so that they didn’t have to run on a particular CPU, and didn’t know anything about which console was which. Source: The Big Book of RSX Applications, Volume II, Appendix
