On Fri, 1 Mar 2002, Blaz Zupan wrote:

> > I doubt the DECstation boot monitor will like an a.out image, anyway; the
> > native Ultrix executable format was ECOFF.

 The MOP loader in the DECstation (REX, at least) only accepts raw data. 
Specifically it only cares about two parameters: the load address and the
transfer address.  Data from MOP packets received from the network is
written to memory unmodified at load addresses specified in them (MOP
headers are stripped off).  When a transfer finishes, a transfer address
is retrieved from the last MOP packet (as well as a few other parameters
that are from then on available to a program in REX variables) and the ROM
executes a jump to that place.

 Whatever format is supported by mopd, it's converted to raw data on the
fly before sending packets away to a network.

> I don't know, but the manpage for mopd says:
> 
>      mopd supports two kinds of files. The first type that is check is if the
>      file is in a.out(5) format. If not, a couple of Digital's formats are
>      checked.
> 
> It doesn't mention ecoff anywhere (although I've tried with ecoff), that's why
> I converted it to a.out.

 A.out isn't likely to work for the DECstation, as it implies a low load
address -- it's 0x0 (first page) or 0x1000 (second page), depending on the
a.out variation, while the MIPS MMU requires the load address to lie in
KSEG0 (0x8000000 - 0x9fffffff) or KSEG1 (0xa000000 - 0xbfffffff).  The
PMAX Digital format doesn't work either (if you find a way to create such
an image), as there is no way to specify such a high load address (the
limit is 0x1fffe00), probably due to a bug in mopd.

 I've been very successful with booting ELF images via MOP using my
modified mopd.  Sources (the original mopd 2.5.3 ones from
'ftp://ftp.stacken.kth.se/pub/OS/NetBSD/mopd/') and patches are available
at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/mopd/'.  They were used to boot
different Linux releases plenty of times on the DECstation successfully
(firmware versions tested: KN03 V5.1b, KN03 V5.2b, KN05 V2.1k).  They seem
to work for Linux on the VAX platform as well (not much tested, though).
Both ELF32 and ELF64 images are supported.  They were tested on an
i386/Linux system but should work for other ones as well.  They shouldn't
depend on the endianness -- well, the ELF support surely does not, neither
do others, as far as I can see.

 There is a PMAX Digital fix (workaround?) included as well.  Also only
Ethernet is supported at this stage -- FDDI is not. 

 If you find them working for you, I'd be pleased to hear about it.  You
may use mopchk to verify your ELF image is seen correctly.  For an example
Linux image I'm getting:

$ file vmlinux
vmlinux: ELF 32-bit LSB mips-1 executable, MIPS R3000_LE [bfd bug], version 1 MathCoPro/FPU/MAU Required (SYSV), statically linked, not stripped
$ objdump -fp vmlinux

vmlinux:     file format elf32-tradlittlemips
architecture: mips:3000, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x80040464

Program Header:
0x70000000 off    0x002d7250 vaddr 0x80317250 paddr 0x80317250 align 2**2
         filesz 0x00000018 memsz 0x00000018 flags r--
    LOAD off    0x00001000 vaddr 0x80040000 paddr 0x80040000 align 2**12
         filesz 0x002bc1f0 memsz 0x002bc1f0 flags r-x
    LOAD off    0x002be000 vaddr 0x802fe000 paddr 0x802fe000 align 2**12
         filesz 0x0004d000 memsz 0x0006b880 flags rwx
private flags = 1: [no abi set] [mips1] [not 32bitmode]

$ mopchk vmlinux
Checking: vmlinux
ELF 32-bit LSB executable
Size of seg #00:    002bc1f0 (+ 00001e10 fill)
Size of seg #01:    0004d000 (+ 0001e880 fill)
Load Address:       80040000
Transfer Address:   80040464

 I wasn't actually going to release information about the patches here
until I get ECOFF support integrated (I received negative feedback when I
asked at this list if anyone's interested in ELF support in mopd), but due
to my time constraints it looks like it isn't going to happen anytime soon
and hesitating to provide help when I can would seem malicious to me. 

 Good luck.

  Maciej

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