On Tue, 8 Feb 2000, Jonathan Stone wrote:

> Uh, this was using the Ultrix 4.2a mopd and config tools, not the
> OpenBSD-derived code.  Some PROM revisions on some models of 3100s at
> Stanford would not MOP-boot large kernels.  (This was mop-booting
> Stanford V-kernels, around 1992. I could try and find the internal manpages
> I wrote then, if you really truly care).

 Ah, I wouldn't call this fact "the machine doesn't MOP-boot properly"; it
just has a certain limitation which might have been introduced on purpose
expecting that the machine may have not enough RAM (and rememeber the
firmware copies parts of itself to RAM, too).  Especially as 3100s are the
oldest systems.  I wouldn't expect them to TFTP-boot any larger images
even if they TFTP-boot at all.

 The limitation was then loosened over time when both the code and the
equipment got improved.

> My recolletion is that MOP over Ethernet isn't routable: its an
> end-node-only thing.  I could be wrong, but that's what I recall.

 BOOTP broadcasts aren't routable, either, yet helpers exist (called BOOTP
relays) which turn them into routable unicasts.  Given MOP specs I believe
it's doable, too.

> Great, thanks for doing that.  But the code is still buggy, right?

 Some bugs are in exiting backends.  They'll probably remain unless
someone else fixes them.  If I find any within the core, I'll surely fix
them when implementing ELF support. 

> ECOFF would be nice to have, since that's what the DECstation PROMs
> support for tftp, and it may make life slightly easier for anyone
> migrating from the DEC mop services (e.g., Ultrix bootservers;
> I think Simon still uses those).

 Hmm, I am afraid I know ELF only and I don't actually think I like the
idea of digging into (E)COFF -- you have to convert an image into a raw
binary format on the fly and that's easy for ELF regardless of the
platform the ELF image is for.  I don't even have COFF specs.  Doesn't the
kernel compile into ELF (I don't know for sure, although I believe so; I'm
actually a Linux developer)?

 Supporting COFF for booting proprietary software (such as Ultrix or
software for terminal servers, etc.) might certainly be worthwhile but I
cannot undertake the task.  The magic numbers are different for every
system and there is also the endianness issue -- I've observed some
systems use native endianness while others always use big endianness for
headers (in ELF you just have a field telling what endianness the image is
and you know whether you need to byteswap headers or not).  I couldn't
even test the results -- all I have is one DS5000/240 and one PC.

 On the other hand -- you may convert (E)COFF images into ELF using
objcopy -- it might be the easier way. 

> In a perfect world we'd TFTP-load a standalone bootloaer that got the
> kernel via NFS from the diskless root. But we're not quite there yet.

 It sounds reasonably.  I'm not sure whether the firmware of network cards
supports sending and receiving frames -- otherwise you'll have to include
a bunch of drivers for various cards (think FDDI or WAN).

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