Re: VS3100M76 - current

[Holm Tiffe <holm%freibergnet.de@localhost>]

David Brownlee wrote:

> On 21 May 2014 11:31, Holm Tiffe <holm%freibergnet.de@localhost> wrote:
> 
> > Holm Tiffe wrote:
> >
> > Since booting thakes that long wfrom a CD, I've decided to try Netbooting
> > again, but this isn't possible without some work.
> >
> > There are netboot files provided for mop.
> > If you look deeper on this, you will see that those files are ELF format,
> > and at least my FreeBSD mopd from the ports isn't able to boot them.
> > I had to use mopcopy to build a mopfile from them, but unfortunately
> > a look to the sources brings up this:
> >
> > mopcopy.c:
> >
> > #ifndef NOELF
> > # if defined(__NetBSD__)
> > #  include <sys/exec_elf.h>
> > # else
> > #  define NOELF
> > # endif
> > # if !defined(EM_VAX)
> > #  define EM_VAX 75
> > # endif
> > #endif /* NOELF */
> >
> > That means ELF is supported on NetBSD, on nothing other. I don't even try
> > to compile the needed support in.
> >
> > I've hacked this a year before and I have a 32bit FreeBSD mopcopy that does
> > the job, but I don't have the sources anymore and my workstation is a 64bit
> > system now. (I've hacked in the netboot because I needed to add support
> > for the rtVAX SGEC)
> >
> 
> Its *possible* that NetBSD's mopcopy's ELF support might Just Work on
> FreeBSD if it was enabled. It might certainly be work testing. If it does,
> or it just needs a small patch then it would make sense to import it into
> the NetBSD tree.

There is something todo, the Makefile Architecture is different and some
other differences are there too, but it isn't impossible, I've compile this
last year more or less per hand.
> 
> Another though might be to try building the NetBSD mopd on FreeBSD - again
> patches could be imported and we could even make the source available for
> separate packaging.

Thats what I've done. FreeBSDs mopd is derived and "scaled" down from
NetBSD anyway.

> 
> So please guys, since I don't know how this would work out on other server
> > architectures, could you please provide an a.out mop file which will work
> > on NetBSD AND the other Architectures? The needed converter is build on
> > NetBSD anyways...
> >
> 
> The problem is that anything which is used in the NetBSD build must be
> built as a tool and supported on all build platforms, so if mopcopy worked
> on FreeBSD, Linux, etc, then it could be enabled in the build to generate
> an a.out as well as an elf kernel image.

:-)

in the history that specific boot file hat the right format, don't ask me
now, NetBSD 4 or 5..

Just say no and NetBSD is the only OS that can boot NetBSD.
MOP is a VAX only protocol anyway and I don't think that the mop-able
NetBSD boot is build on every other architecture - since it isn't needed
there. You can't boot other things as VAXen with that, so if you build it
for VAXen you can build it in the right format.
> 
> 
> >
> > The next thing with that file is this:
> >
> > netio.c from NetBSD VAX boot:
> >
> >          * Get info for NFS boot: our IP address, our hostname,
> >          * server IP address, and our root path on the server.
> >          * There are two ways to do this:  The old, Sun way,
> >          * and the more modern, BOOTP way. (RFC951, RFC1048)
> >          */
> >
> > #ifdef SUPPORT_BOOTP
> >
> >         /* Get boot info using BOOTP way. (RFC951, RFC1048) */
> >         printf("Trying BOOTP\n");
> >         bootp(0);
> >
> >         if (myip.s_addr) {
> >                 printf("Using IP address: %s\n", inet_ntoa(myip));
> >
> >                 printf("myip: %s (%s)\n", hostname, inet_ntoa(myip));
> >         } else
> >
> > #endif /* SUPPORT_BOOTP */
> >         {
> > #ifdef  SUPPORT_BOOTPARAMS
> >                 /* Get boot info using RARP and Sun bootparams. */
> >
> >                 printf("Trying BOOTPARAMS\n");
> >                 /* Get our IP address.  (rarp.c) */
> >                 if (rarp_getipaddress(0) == -1)
> >                         return (errno);
> >
> >                 printf("boot: client IP address: %s\n", inet_ntoa(myip));
> >
> >                 /* Get our hostname, server IP address. */
> >                 if (bp_whoami(0))
> >                         return (errno);
> >
> >                 printf("boot: client name: %s\n", hostname);
> >
> >                 /* Get the root pathname. */
> >                 if (bp_getfile(0, "root", &rootip, rootpath))
> >                         return (errno);
> > #endif
> >         }
> >         printf("root addr=%s path=%s\n", inet_ntoa(rootip), rootpath);
> >         f->f_devdata = s;
> >
> >
> >
> > someone decided that there is a modern way: "The old, Sun way,
> >          * and the more modern, BOOTP way. (RFC951, RFC1048)"
> >
> > BOOTP is providing a root-path, but nobody inide "boot" is interested in
> > that root-path:
> >
> > Trying BOOTP
> > Using IP address: 192.168.50.22
> > myip: vs3176 (192.168.50.22)
> > root addr=192.168.50.49 path=
> > nfs_open: must mount first.
> > open netbsd.gz: Device not configured
> > netbsd.gz: boot failed: Device not configured
> > > boot netbsd.old
> >
> > wireshark says that my DNSMASQ from my Linksys Router is providing one:
> >
> > "Boot file name: /tftpboot/netbsd-vax"
> >
> > So why this is leaved unnused?
> > In libsa the bootfile is rad but the variable is unnused.
> >
> 
> You're definitely seeing an entry with TAG_ROOTPATH (17) in the packet?

To late. I've closed that windows. I had todo some work...
> 
> It is really not that easy to dig with an VAX and NetBSD if you not already
> > have a VAX with a running NetBSD. I've had setup a cross development tree 1
> > year before, but I have this todo again it seems..
> >
> 
> Because the standard NetBSD cross development environment is supposed to be
> so easy to setup on any posix platform, we tend to assume its present.
> 
> I think the issues here are in addition to the cross development
> environment - let see what we can do to make it less painful to start
> working with NetBSD/vax :)

Yes, it is relativley easy, but it needs time to setup.
I do even have a 32Bit FreeBSD in a VirtualBox just had to transfer the
entire stuff but then it is a 6.0 from last year..

Regards,

Holm

-- 
      Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
     Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, info%tsht.de@localhost, Fax +49 3731 74200, Mobil: 0172 8790 741