> I'm wondering; is there a FAQ? And if not, can I ask this: What is the
> status of the port?

The port appears to be very young at this point - I'm hoping to give it
a go this weekend, but there are many challenges in order to be able to
match the port developer's configuration I think.

You'll need a serial cable in order to talk to the NeXTstation, you'll
need a net host system, e.g. NetBSD/i386 box (there is an i386->m68k
toolchain in the snapshot from what I can see), you'll need to be able
to configure dhcpd to allow the NeXT box to netboot... but having yet
to try all this, I really should let the snapshot README speak for itself.

-- Ken

P.S. Snapshot is under ftp://ftp.netbsd.org/pub/NetBSD/arch/next68k/

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

% cat 00-README

This is a snapshot of an experimental port of the netbsd
to the 68k NeXT machines.  Currently, it can netboot and run
via a console on the serial port well enough to compile itself.
There no support for the scsi disk, keyboard, or display yet.
If you are interested in contributing to this port, please
contact me!

Darrin B. Jewell <dbj@netbsd.org> Tue Jun  9 04:53:43 1998

Some notes:

The sources for the arch/next68k kernel tree from which
this was built are in.

  next68k-snapshot-19980607.tgz

The kernel images, with and without debugging info are:
  netbsd-GENERIC.gz
  netbsd.gdb-GENERIC.gz

The bootloader is the file:
  boot

and the following files are the standard filesystem images:
  base.tgz
  comp.tgz
  etc.tgz
  games.tgz
  man.tgz
  misc.tgz
  text.tgz

dhcpd.patch is needed to boot the NeXT using the netbsd dhcpd.

Unfortuntely, when I created this snapshot, I didn't realize
that some of the files in etc were hacked.  You might
notice some weird stuff in /etc/rc.conf, for example.

The NeXT can boot via bootp, but needs to a bootp that returns
the vendor string back to the NeXT.  I believe the NetBSD bootp
does this, but I have not personally tried it.  I have been using
dhcpd someone hacked to do this instead.  If you need the dhcpd
patch, send me email, although hopefully it'll get integrated into
the normal dhcp tree before too long.

Here's a note from Rolf Grossman
about setting up bootp to boot the NeXT:

>While I'm having problems getting boopd started from inetd, I've got
>it working when using bootpd as a daemon. The trick is to set the
>vendor magic to auto, because NeXT seem to use a different scheme
>than NetBSD. Here is the bootptab I'm using:
>
># bootptab
>black.securitas.net:\
>        :ht=ether:\
>        :ha=00000F006695:\
>        :sm=255.255.255.224:\
>        :lg=194.121.52.19:\
>        :gw=194.121.52.28:\
>        :ip=194.121.52.21:\
>        :hn:\
>        :bf=/tftpboot/boot.netbsd:\
>        :rp=/export/src/devnetbsd/m68k-netbsd:\
>        :vm=auto:


If you use bootp, it needs to get the bootloader via tftp.
The bootloader does deal with scsi disks so the kernel
can be launched off of a NeXTstep partition instead if you want.
Once booted, however it still needs an nfs server for its root
filesystem.

I also noticed that I needed to have the bootp server publish
the arp entry for the NeXT since the NeXT didn't seem to be
able to arp for itself at some point in the bootstrap.
I just use "arp -s milo.mit.edu 00:00:0f:00:73:d1 pub" to set
this on the server, and everything works okay. (milo is a NeXT)

It currently only runs on 68040 NeXT and has been tested on
two fairly similar 25Mhz 68040 NeXTs.  There is some code
in locore that uses 68040 instructions to turn on the MMU,
although it shouldn't be too hard to make the '030 work.

I don't know how well it will probe memory configurations on
other machines, but I hope it will at least manage ok.

Please let me know if you manage to get it booted.  I am planning
on committing the current sources to the NetBSD cvs tree soon and
would like to know that someone else got it working first.  I
haven't yet actually downloaded the snapshot myself and tried
to set it up, but the executables in it are the ones I'm currently
running.

The ethernet driver is mostly stable.  Mine usually stays up
for a couple of days, but I have observed it panicing in
a diagnostic check in the DMA driver where I didn't expect it to.
Almost all of the DMA code was guesswork and experimentation.

Hopefully, the DMA driver was the bottleneck and the rest of the
work should be straightforward from here.  There's a lot that
needs doing and I am hoping other people are interested in hacking
on it.  If you think you might be able to work on something, please
speak up!


Darrin