On Tue, 8 Feb 2000, Jonathan Stone wrote:

> Not entirely. WE can't just switch to MOP: there are PROM revisions
> which don't MOP-boot reliably, either.  And MOP doesn't really work
> through gateways.

 That would be strange -- it is an official way of booting DEC equipment,
it has been documented everywhere and supposedly it was thoroughly tested.
How are you sure it's a problem with a MOP client and not a server.  Given
the mopd out there (I refer to version 2.5.3) is buggy as hell...

 You should probably be able to MOP-boot via a DECnet router.  Of course
the router would have to support it -- I'm not sure if one exists -- I'm
just judging based on the protocol.  Actually I find MOP nicer for
networks as it uses multicasts for the initial query unlike BOOTP which
uses broadcasts (probably just because nobody thought of reserving a group
for BOOTP...).

> Yes, it would be very nice if we had a pmax MOP loader. Unfortunately,
> the authors of the existing MOP implementations were a little
> VAX/a.out-centric.  If you (or anyone else) wanted to fix that,
> though, it'd be a great project.

 In fact, I got tired of hardcoding the load and transfer addresses into
mopd every time I compile an image with a different layout.  I'll be
writing an ELF backend for mopd in a few days.  I'll send a patch here,
when it's ready. 

 I think going ELF is the only reasonable solution as it gives us platform
independence -- one can use a single server binary to supply images for
MIPS, VAX or whatever; not sure of Alpha -- it seems the protocol does not
support 64-bit addressing.  The current aout support does heavily depend
on magic numbers which are system specific.  And the current support for
DEC MOP images is a joke -- look at PMAX image macros, for example --
different fields seem to overlap in an unresolveable way. 

 I've been able to successfully MOP-boot 2.5 MB images on V5.1b KN03-AA,
BTW.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +