Re: Mopd which works with ELF and a.out in Linux and can netboot ULTRIX

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

Hi Boris,

> Thank you for sharing your version of mopd. I've converted the patches into
> git commits and put the result at
> https://github.com/dreamlayers/netbsd-mopd/tree/mwr. In the last commit I do
> what's necessary to make it build on Ubuntu 20.10, and fix the obvious
> warnings.

 Thank you for this effort.

> With it I can mopcopy
> https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/vax/installation/netboot/boot
> and get it that to boot from mop format. Directly attempting to boot it in ELF
> format via mopd falsely assumes load address is 007f0000 and fails. Changing
> that to zero via a "p.p[0].paddr = 0" in GetELFFileInfo() makes it work. I
> didn't investigate what's going on there and what's the proper fix.

 My implementation of the ELF interpreter in `mopd' uses the LMA addresses 
of individual segments for loading purposes, as per the ELF gABI (so that 
you can have VMA != LMA, e.g. if real addresing is used for loading and 
then virtual addressing is switched on later on; this will be specific to 
the individual MOP client's processor and operating configuration).  Also 
it sends the client the entry point as it is from the ELF file header.

 Yes, I have noticed that VAX/NetBSD ELF MOP boot images have been broken 
since NetBSD 4:

$ readelf -hl cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/vax/installation/netboot/boot
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Digital VAX
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          70048 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         8
  Section header string table index: 7

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000054 0x007f0000 0x007f0000 0x11050 0x13840 RWE 0x4

 Section to Segment mapping:
  Segment Sections...
   00     .text .rodata .data .bss
$ mopchk cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/vax/installation/netboot/boot
ELF 32-bit LSB executable
Size of seg #00:    00011050 (+ 000027f0 fill)
Load Address:       007f0000
Transfer Address:   00000000
$ 

and figured out what the proper fix is by comparing them to the old a.out 
images (which got the addresses right).  It can be easily done with 
`objcopy', e.g.:

$ objcopy --adjust-vma -0x7f0000 --set-start 0x7f0000 cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/vax/installation/netboot/boot boot
$ mopchk boot
Checking: boot
ELF 32-bit LSB executable
Size of seg #00:    00011050 (+ 000027f0 fill)
Load Address:       00000000
Transfer Address:   00000000
$ 

(with `--adjust-vma' the entry point is relocated accordingly, so you need 
to cancel the adjustment with `--set-start').

 I mentioned it to Ragge the other day; as a relative newcomer to NetBSD I 
have no idea where the problem comes from.  It looks to me like an odd 
build issue, likely one in the linker script used to make this image; 
perhaps something to do with LMA vs VMA, as noted above (i.e. the VMA is 
correct as per the interpretation of code executed and the symbol table, 
and it's only LMA that ought to be adjusted).

 I don't know what any other `mopd' implementations do that makes the ELF
image work with them.  I have successfully used my `mopd' implementation 
to boot all kinds of DEC equipment and images: 32-bit ELF, 64-bit ELF (for 
R4k DECstations), and non-ELF, built by myself and by DEC (e.g. a console 
firmware update for VAXstation 4000), e.g.:

$ mopchk vmlinux-4maxp64.SYS
Checking: vmlinux-4maxp64.SYS
ELF 64-bit LSB executable
Size of seg #00:    00682840 (+ 00043a00 fill)
Load Address:       80040000
Transfer Address:   8053de30
$ 

> The ELF support there is totally different from NetBSD mopd, using libelf.

 I chose to use libelf so as not to reinvent the wheel, :) and to follow 
the *nix's principle of treating the system as a set of building blocks to 
combine and reuse.  I think the library is universally available nowadays, 
and it was quite common 20 years ago already.

> Both NetBSD (in the dreamlayers branch) and this mwr branch start with the
> same mopd-2.5.3.tar.gz code, with only differences in version control IDs. But
> they diverge, handling some of the same issues but separately.

 This just proves independent thinking. :)

> There definitely is some code there which would be useful for NetBSD. I'm not
> saying I'm going to do that though. I need to be doing what I love with my
> free time. Making little changes to mopd which already works to my
> satisfaction probably won't be something I love, and can easily turn into a
> sense of obligation and/or desire to please others.

 Completely understood.  Thank you again for taking your time to make this 
effort and this analysis.  All the small steps build up.

  Maciej