On 2013-05-17 17:18, John Wilson wrote:
From: "Bob Armstrong" <bob at jfcl.com>
I thought I remembered that the Ethernet interfaces could do it, but how
does that work?
Sneakily. It's in the DEUNA/DELUA manuals. They DMA a small program into
memory, including the power fail vector (24/26 I think?) which points at
it, and then fake a power failure while blocking INIT L to themselves.
Obviously this is a ridiculous security risk (I guess they assumed the
ethernet coax was physically secure) so that's why MOP had a magic number
(which could be 0 in earlier versions but not in later revs).
Your memory is way better than mine. :-)
Thanks. That summary made me recall details.
The DEQNA/DELQA were kludgier and I'm drawing a blank on whether they even
support network-triggered booting.
I think I remember seeing the DELQA being able to.
The
DEUNA/DELUA/DEQNA/DELQA has no reason to implement DDCMP, although it
certainly had enough local CPU power to do so. Did it still scan for MOP
trigger messages anyway?
DEUNA/DELUA support MOP dump/load/sysID (as well as ECT echo) in firmware,
I'm blanking on which parts of MOP the DELQA knows innately (I think at least
enough to send system IDs), and the DEQNA is too mindless to do anything
w/o driver help.
:-)
Johnny
From: "Bob Armstrong" <bob at jfcl.com>
I thought I remembered that the Ethernet interfaces could do it, but how
does that work?
Sneakily. It's in the DEUNA/DELUA manuals. They DMA a small program into
memory, including the power fail vector (24/26 I think?) which points at
it, and then fake a power failure while blocking INIT L to themselves.
Obviously this is a ridiculous security risk (I guess they assumed the
ethernet coax was physically secure) so that's why MOP had a magic number
(which could be 0 in earlier versions but not in later revs).
The DEQNA/DELQA were kludgier and I'm drawing a blank on whether they even
support network-triggered booting.
The
DEUNA/DELUA/DEQNA/DELQA has no reason to implement DDCMP, although it
certainly had enough local CPU power to do so. Did it still scan for MOP
trigger messages anyway?
DEUNA/DELUA support MOP dump/load/sysID (as well as ECT echo) in firmware,
I'm blanking on which parts of MOP the DELQA knows innately (I think at least
enough to send system IDs), and the DEQNA is too mindless to do anything
w/o driver help.
John Wilson
D Bit
On May 17, 2013, at 10:32 AM, Bob Armstrong wrote:
I thought the DELQA did? I don't think the DEQNA did, however.
Also, the DEUNA and DELUA handles it, as far as I know.
I thought I remembered that the Ethernet interfaces could do it, but how
does that work? The DMR required that you have a M9312 with the appropriate
boot ROMs - were there NI boot ROMS for the M9312 too? How did the DELQA do
it (i.e. which QBUS PDP-11 CPU had an NI boot ROM)?
Also, the DMR was smart enough to implement DDCMP in "hardware" and so it
understood MOP at least well enough to detect the TRIGGER message. The
DEUNA/DELUA/DEQNA/DELQA has no reason to implement DDCMP, although it
certainly had enough local CPU power to do so. Did it still scan for MOP
trigger messages anyway? Or was the Ethernet trigger implemented
differently?
MOP is a protocol that's defined both for point to point links (DDCMP) and Ethernet, though some bits (like Sysid) apply only to one of those. But the Boot message (NCP TRIGGER) is common to both.
The implementation of the boot message depends on machinery outside the CPU that can recognize and validate the boot message, and make the CPU reboot. So it's not very common -- boot support doesn't make any sense in a software DDCMP implementation, or a software MOP on Ethernet implementation. The reason is that it would only work if the software on the CPU is sane, which is precisely when you do not need to force a boot.
So you only see it on controllers that have their own microprocessor to implement that part of MOP, and they need the ability to force a CPU restart from where they sit on the I/O bus. Unibus does that; I forgot if Qbus does. DMC and DMC have the necessary microprocessor, as do UNA and LUA. QNA does not. LQA has a microprocessor and could do this in principle, but I'm not sure if it actually does. KMC could, if it wanted to, but here too I don't know if anyone has done it.
Note that downloading a system is separate from boot/trigger. Download requires a boot rom that talks to the network device to speak the MOP Load protocol. You can do that whenever the system restarts; it might be because of a power fail or crash. Conversely, it's possible for a MOP Boot (trigger) to reset the CPU and have that result in a boot from local storage, such as disk or tape. That's probably not common but the two operations are separate and it's certainly valid for that to be the result.
paul
On 2013-05-17 16:32, Bob Armstrong wrote:
I thought the DELQA did? I don't think the DEQNA did, however.
Also, the DEUNA and DELUA handles it, as far as I know.
I thought I remembered that the Ethernet interfaces could do it, but how
does that work? The DMR required that you have a M9312 with the appropriate
boot ROMs - were there NI boot ROMS for the M9312 too? How did the DELQA do
it (i.e. which QBUS PDP-11 CPU had an NI boot ROM)?
Actually, this is a bit more complex, as well as me not being 100% sure about all the details. But essentially, yes, there are boot ROMs for the DEUNA/DELUA, but they are not involved when you do a trigger command.
As for the Qbus machines, the 11/73/83/93 all can boot from ethernet with the standard boot roms, unless I remember wrong (you just need the right revision). However, I believe that these too are not used when you do a MOP trigger.
As far as I remember (I seem to remember this being documented in the DEUNA and DELUA manuals), at a MOP trigger command, the ethernet card resets the bus, and then it forces the CPU to jump into boot code provided by the ethernet controller. This is done by forcing a different restart vector for the CPU. And yes, the controller have PDP-11 code in ROM, for booting. It just makes this code appear in the I/O page for the CPU to execute, at trigger time.
The boot ROM is needed when you want to network boot from scratch, as there is no MOP trigger to activate the ethernet controller in that case. It's actually three ROMs for the M9312 to implement the NI booting. But for just the trigger boot, those ROMs are not used, or needed.
Also, the DMR was smart enough to implement DDCMP in "hardware" and so it
understood MOP at least well enough to detect the TRIGGER message. The
DEUNA/DELUA/DEQNA/DELQA has no reason to implement DDCMP, although it
certainly had enough local CPU power to do so. Did it still scan for MOP
trigger messages anyway? Or was the Ethernet trigger implemented
differently?
Of course. DDCMP has nothing to do with this. MOP is defined over Ethernet as well. And yes, the controllers understand and handle some MOP packets internally in the controllers, if needed.
Johnny
On 2013-05-17 16:18, Bob Armstrong wrote:
On 2013-05-16 18:28, Johnny Billquist wrote:
This is a totally volontary thing. I've finally come to the point
where I think that there are a few more pieces of data on nodes
that would be nice/useful to have from time to time.
Much of the information you want (all of it, I think) is already in the
INFO.TXT file -
$ type legato""::info.txt
....
ADDR |NAME |OWNER |EMAIL |HARDWARE |OS
|LOCATION |NOTES
2.1 |LEGATO|Bob Armstrong |bob at jfcl.com |simh |OpenVMS
7.3|Milpitas, CA, US|DCN Multinet Ro
uter
2.2 |POCO | | |MicroVAX-2000 |
| |6MB, RD54, TK50
2.4 |MEZZO | | |PDP-11/53 |RSTS
| |3.5MB, 2xRA73,TK70, SCSI
2.6 |LARGO | | |VAX-11/730 |VMS 4.7
| |R80, 2xRA81, RL02, RX02, TU80
2.7 |CODA | | |DS20E |OpenVMS
8.3| |
2.9 |DIVISI| | |VAX-8350 |VMS 5.5-2
| |16MB, RA81, RA82, TU81+
2.10 |ADAGIO| | |VAXserver 3900 |VMS 6.0
| |RA81, RX50, 2xRD54, Kennedy 9610, RRD50, RF31, 2xRF71,
RF72, SQ703, Exabyte 8505
2.11 |LENTO | | |PDP-11/73 |RSX-11M+
| |2xRD32, RX50, RL02, Kennedy 9600
2.12 |JENSEN| | |DEC 2000 axp |OpenVMS
7.3| |
2.13 |ZITI | | |eBox-3310 |Ubuntu
| |
2.14 |MULTIA| | |Multia UDB |OpenVMS
7.3| |
2.15 |PAVANE| | |DECstation 3100 |Ultrix
| |MIPS box w/DECnet-Ultrix
2.16 |SKETTI| | |HP ProLiant ML110G4 |Ubuntu
| |
2.18 |DSRVB1| | |DECserver-200/MC |
| |
2.19 |DSRVB2| | |DECserver-200/MC |
| |
FWIW, keeping a central database up to date is going to be a nightmare -
that's why we invented the INFO.TXT files; so each sysadmin could locally
update his own information.
Yes. I know... :-)
Which I said this is all voluntary and so on. I've just felt that the INFO.TXT is not really working that well either. At least not from my point of view. I'm willing to try different things. I could consider some automatic scraping and population of the nodename database from some distributed sources as well, if we can come up with something that seems reasonable.
Oh, and thanks.
Johnny
On Fri, 17 May 2013 06:49:40 -0700, you wrote:
DECnet (NCP) has a TRIGGER command that sends a special MOP message to a
remote machine, and that's supposed to force the machine to do a hard reset
and the reboot, presumably via DECnet.
It uses MOP, not DECnet. Although MOP is described among other DECnet
standards and managed with NCP, it does not use DECnet protocols to do its
thing. IIRC it does not even use NETDRIVER & Co. but its own NDDRIVER. :)
The problem is that it doesn't seem like there are many PDP-11 or VAX
communications interfaces that actually implement this. The DMR and DMC
appear to, but as far as I can find those are the only ones. In particular
there don't appear to be any QBUS interfaces that can do it. Have I missed
any? Has anybody ever done this? What interface did you use?
Years ago I made some experiments with CONNECT (and TRIGGER) and a DEC 3000
Alpha workstation. It worked (somewhat), but only if the host was waiting at
the >>> prompt. If that was the case, it was possibile to connect to the SRM,
type commands and receive responses. I do not remember if TRIGGER would start
the boot process or if it did not work. I had the overall feeling that the
DEC 3000 firmware code managing those functions was not very well tested and
debugged as it locked the whole machine quite often...
HTH, :)
G.
I thought the DELQA did? I don't think the DEQNA did, however.
Also, the DEUNA and DELUA handles it, as far as I know.
I thought I remembered that the Ethernet interfaces could do it, but how
does that work? The DMR required that you have a M9312 with the appropriate
boot ROMs - were there NI boot ROMS for the M9312 too? How did the DELQA do
it (i.e. which QBUS PDP-11 CPU had an NI boot ROM)?
Also, the DMR was smart enough to implement DDCMP in "hardware" and so it
understood MOP at least well enough to detect the TRIGGER message. The
DEUNA/DELUA/DEQNA/DELQA has no reason to implement DDCMP, although it
certainly had enough local CPU power to do so. Did it still scan for MOP
trigger messages anyway? Or was the Ethernet trigger implemented
differently?
Bob
On 2013-05-16 18:28, Johnny Billquist wrote:
This is a totally volontary thing. I've finally come to the point
where I think that there are a few more pieces of data on nodes
that would be nice/useful to have from time to time.
Much of the information you want (all of it, I think) is already in the
INFO.TXT file -
$ type legato""::info.txt
....
ADDR |NAME |OWNER |EMAIL |HARDWARE |OS
|LOCATION |NOTES
2.1 |LEGATO|Bob Armstrong |bob at jfcl.com |simh |OpenVMS
7.3|Milpitas, CA, US|DCN Multinet Ro
uter
2.2 |POCO | | |MicroVAX-2000 |
| |6MB, RD54, TK50
2.4 |MEZZO | | |PDP-11/53 |RSTS
| |3.5MB, 2xRA73,TK70, SCSI
2.6 |LARGO | | |VAX-11/730 |VMS 4.7
| |R80, 2xRA81, RL02, RX02, TU80
2.7 |CODA | | |DS20E |OpenVMS
8.3| |
2.9 |DIVISI| | |VAX-8350 |VMS 5.5-2
| |16MB, RA81, RA82, TU81+
2.10 |ADAGIO| | |VAXserver 3900 |VMS 6.0
| |RA81, RX50, 2xRD54, Kennedy 9610, RRD50, RF31, 2xRF71,
RF72, SQ703, Exabyte 8505
2.11 |LENTO | | |PDP-11/73 |RSX-11M+
| |2xRD32, RX50, RL02, Kennedy 9600
2.12 |JENSEN| | |DEC 2000 axp |OpenVMS
7.3| |
2.13 |ZITI | | |eBox-3310 |Ubuntu
| |
2.14 |MULTIA| | |Multia UDB |OpenVMS
7.3| |
2.15 |PAVANE| | |DECstation 3100 |Ultrix
| |MIPS box w/DECnet-Ultrix
2.16 |SKETTI| | |HP ProLiant ML110G4 |Ubuntu
| |
2.18 |DSRVB1| | |DECserver-200/MC |
| |
2.19 |DSRVB2| | |DECserver-200/MC |
| |
FWIW, keeping a central database up to date is going to be a nightmare -
that's why we invented the INFO.TXT files; so each sysadmin could locally
update his own information.
BOb
On 2013-05-17 15:49, Bob Armstrong wrote:
DECnet (NCP) has a TRIGGER command that sends a special MOP message
to a remote machine, and that s supposed to force the machine to do a
hard reset and the reboot, presumably via DECnet. It s for machines
that are located in remote locations where there s no operator around to
conveniently flip the RESTART toggle.
The problem is that it doesn t seem like there are many PDP-11 or VAX
communications interfaces that actually implement this. The DMR and DMC
appear to, but as far as I can find those are the only ones. In
particular there don t appear to be any QBUS interfaces that can do
it. Have I missed any? Has anybody ever done this? What interface
did you use?
I thought the DELQA did? I don't think the DEQNA did, however.
Also, the DEUNA and DELUA handles it, as far as I know.
Johnny
DECnet (NCP) has a TRIGGER command that sends a special MOP message to a remote machine, and that s supposed to force the machine to do a hard reset and the reboot, presumably via DECnet. It s for machines that are located in remote locations where there s no operator around to conveniently flip the RESTART toggle.
The problem is that it doesn t seem like there are many PDP-11 or VAX communications interfaces that actually implement this. The DMR and DMC appear to, but as far as I can find those are the only ones. In particular there don t appear to be any QBUS interfaces that can do it. Have I missed any? Has anybody ever done this? What interface did you use? Thanks,
Bob