HECnet

hecnet@lists.dfupdate.se

7 participants
15595 discussions

Which DECnet interfaces support remote, unattended, booting?

by Paul_Koning＠Dell.com

On May 17, 2013, at 12:07 PM, Bob Armstrong wrote: Paul_Koning at Dell.com wrote: Boot.1 == ... Boot.2 == ... In my DLV11 example, boot.1 == "RESET" and "JMP @#173000" (and by "RESET", I mean the PDP11 instruction RESET). After that, the BDV11 (or KDF11B, KDJ11 or whatever) takes care of boot.2. I absolutely admit that it wouldn't always work, but it would work a lot of the time. And a little bit of extra code in the DDCMP driver is "free"... I see your point. Yes, clearly you could look for the MOP Boot message (boot.1) in a software DDCMP driver, and handle that just as you described. And whenever that software driver is operational, the result would be exactly what people expect. The difference with, say, a DMC11 is that the Boot message handling in the DMC still works even if the CPU is halted, while the one in the software DDCMP driver doesn't. But with those limitations it would indeed be a perfectly reasonable/useful thing to do. paul

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by bob＠jfcl.com

Paul_Koning at Dell.com wrote: So you only see it on controllers that have their own microprocessor to implement that part of MOP, One more question and I'll quiet down - it's funny, but as far as I can tell, none of the QBUS synchronous cards could do this. Neither the DPV11 nor DUV11 entries in my handbook say anything about booting. The DPV, in particular, implemented DDCMP (and BISYNC, HDLC, SDLC, and several others) in the controller and was probably at least as powerful as the DMR11, but it doesn't boot. It looks like the DELQA is the only possible option for remote triggering a QBUS 11, and even that one is uncertain.

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by bob＠jfcl.com

Paul_Koning at Dell.com wrote: Boot.1 == ... Boot.2 == ... In my DLV11 example, boot.1 == "RESET" and "JMP @#173000" (and by "RESET", I mean the PDP11 instruction RESET). After that, the BDV11 (or KDF11B, KDJ11 or whatever) takes care of boot.2. I absolutely admit that it wouldn't always work, but it would work a lot of the time. And a little bit of extra code in the DDCMP driver is "free"... Bob

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by bob＠jfcl.com

Johnny Billquist wrote: And on re-reading I see that I misunderstood the comment. Sorry - I left too many words out of the original comment. Gotta remember to be verbose :-) BTW, you are right - I just turned on my 11/83 it does have a "XH" boot in the ROM. I'm guessing that I could set that us as a default boot, and then as long as the DELQA knows enough MOP to force a bus INIT, it'll work. Bob

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by Paul_Koning＠Dell.com

On May 17, 2013, at 11:40 AM, Bob Armstrong wrote: 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. The problem here is that "Boot" has two very different meanings. Boot.1 == the process of forcing a running or halted CPU to reinitialize itself. Boot.2 == the process of loading the operating system or main software into a CPU. For example, boot.1 can be done on a PDP-11 by cycling the power. Boot.2 on a PDP-11 involves running the "boot loader" ROM code, which loads a small program from somewhere, which in turn loads a larger program... finally resulting in the system being fully operational. These two are independent in some sense (though the consequence of boot.1 is that boot.2 is initiated). MOP supports both of these. Boot.1 is performed by the MOP Boot message. Boot.2 is performed by the MOP Load messages. A system may support one or both or neither of these two MOP functions. For example, it might power up into a boot loader ROM that is configured to run MOP Load. (Terminal servers are examples of this.) If so, you might be able to force a restart by sending a MOP Boot message, or that may not be supported. Conversely, at least in theory, a system might support Boot.1, but what happens next is a boot from disk. The "boot support" I was discussing -- the one that requires hardware help -- is Boot.1. By definition it is intended to work when the CPU is not cooperating, so it must be executed in some external hardware, and that hardware has to have the ability to force the CPU to restart. As John Wilson pointed out, on a PDP11 that means yanking on the INIT line while shielding yourself from the consequences. Boot roms that support "DECnet boot" are implementations of Boot.2, i.e., MOP Load. paul

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by bqt＠softjar.se

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

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by bqt＠softjar.se

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

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by bob＠jfcl.com

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

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by bob＠jfcl.com

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

12 years, 10 months

Which DECnet interfaces support remote, unattended, booting?

by bqt＠softjar.se

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

12 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet