On 2013-05-17 17:43, Bob Armstrong wrote:
Johnny Billquist wrote:
Um, no. The "small program" is a program expected to be executed by the
host.
You missed my point - the issue was not "where does the small program
execute from", it was "where is the code for the boot program stored
(permanently) before it gets DMAed into the host".
:-)
Yes. My mistake.
Johnny
On 2013-05-17 17:40, Johnny Billquist wrote:
On 2013-05-17 17:34, Bob Armstrong wrote:
John Wilson wrote:
They DMA a small program into memory
Ah, I was wondering about that, because there aren't any separate boot
ROMs on the DEUNA. I bet the "small program" is just part of the T11
code.
Um, no. The "small program" is a program expected to be executed by the
host.
And on re-reading I see that I misunderstood the comment.
Yes, the program to DMA into the host is located along with all the other code on the controller (a T11 for the DEUNA, and a 68K for the DELUA).
Johnny
Johnny Billquist wrote:
Um, no. The "small program" is a program expected to be executed by the
host.
You missed my point - the issue was not "where does the small program
execute from", it was "where is the code for the boot program stored
(permanently) before it gets DMAed into the host".
Bob
Paul_Koning at Dell.com wrote:
boot support doesn't make any sense in a software
DDCMP implementation ....
I was also wondering if, say, the DLV11 DDCMP driver in DECnet implemented
booting. As you say, it's not as useful as an independent hardware boot in
the controller, but it would work as long as enough of the OS is still alive
to process DLV11 interrupts. You've got maybe a 50-50 chance, but even
still - async DECnet was a low end solution so you expect low end results
:-)
The DDCMP driver wouldn't have to actually do the boot - there is a DECnet
boot ROM for asynchronous interfaces already, and you could just assume that
was already set up. All the DDCMP driver would have to do is start it.
Bob
On 2013-05-17 17:34, Bob Armstrong wrote:
John Wilson wrote:
this is a ridiculous security risk
so that's why MOP had a magic number
Yep, even the DMR has a boot "password", which is just an 8 bit value set
by dip switches on the board, that has to match up with the MOP message.
I don't remember how you set the password on the DEUNA/DELUA, it might be something you programmed, so by default it was a known value, but as soon as the system have started up, it can change it to something else, or even disable the trigger ability (maybe).
They DMA a small program into memory
Ah, I was wondering about that, because there aren't any separate boot
ROMs on the DEUNA. I bet the "small program" is just part of the T11 code.
Um, no. The "small program" is a program expected to be executed by the host.
And I'm assuming that this scheme didn't work on any UNIBUS VAXes - only
PDPs.
Correct. :-)
Johnny
On May 17, 2013, at 11:34 AM, Bob Armstrong wrote:
John Wilson wrote:
this is a ridiculous security risk
so that's why MOP had a magic number
Yep, even the DMR has a boot "password", which is just an 8 bit value set
by dip switches on the board, that has to match up with the MOP message.
They DMA a small program into memory
Ah, I was wondering about that, because there aren't any separate boot
ROMs on the DEUNA. I bet the "small program" is just part of the T11 code.
And I'm assuming that this scheme didn't work on any UNIBUS VAXes - only
PDPs.
That sounds right. The network interface needs a way to tell the machine to restart. On a VAX, the Unibus doesn't do that. In theory you could have a console front end processor that implements MOP Boot message handling and does the restart if it sees one. (The same would be true on PDP-10 or -20 machines that have a front end processor.) In practice, I don't remember that such a thing was ever done.
paul
John Wilson wrote:
this is a ridiculous security risk
so that's why MOP had a magic number
Yep, even the DMR has a boot "password", which is just an 8 bit value set
by dip switches on the board, that has to match up with the MOP message.
They DMA a small program into memory
Ah, I was wondering about that, because there aren't any separate boot
ROMs on the DEUNA. I bet the "small program" is just part of the T11 code.
And I'm assuming that this scheme didn't work on any UNIBUS VAXes - only
PDPs.
Bob
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