so my efforts to get a NeXT to boot all by itself have finally
succeeded.  it requires some kernel changes and a bit of hardware.

first, the hardware:

the NeXTstation will work just fine without a monitor.  the only
difficulty is getting it to power up, since the power switch is on the
keyboard.

this is taken from a NeXT faq available at
ftp://next-ftp.peak.org/next-ftp/next/documents/nextstep_faq

5.42 How to boot a NeXT without a monitor?

    The procedure is to just touch pins 6 and GND on the DB-19 NeXT
   monitor out with a 470 Ohm resistor (450 is the actual resistance, but
   470 ohms is more commonly found in resistors). Pin 6 is the power
   sense, and pins 13-19 (and the DB shell) are the GND. Just say "pin
   19", it may be easier.

   There's a pinout diagram of the DB-19 in the NeXT Users Reference
   Manual.

   If you have an old Cube, the power supply needs to have more power
   drawn from it than an 030 (and 040?) board uses to stay on. So: On the
   DB-19, attach a Power Resistor (20 Ohm, at least 20 Watt) between pins
   12 and GND. (Pin 12 is -12V, pin 13 works well for GND). Then just
   "touch" the 470 ohm resistor as described above, and you're set. The
   20 Ohm resistor draws an old 030 running without monitor in an old
   CUBE), but it isn't necessary - just don't touch it (*HOT!* ;-)

   To power off, type "halt -p" as root on the machine (either through a
   terminal connected to port A, or over the ethernet connection).

   Also, you have to have the Rom Monitor settings done correctly. The
   important ones are:

        Wait until keypress? N
        Sound out tests? N
        Port A as alternate Console? Y (if you have one, it's nice)

(it mentions verbose mode being set to N, but it's wrong.)

indeed, my cube didn't power up, but i wasn't about to try hooking up a
dummy load.  also, there's no information on color machines.  the
technique is probably similar, but the correct pin isn't obvious from
the schematics i have.

fwiw, on a cable i had, pin 6 was the thin brown wire, and it was
twisted around a ground wire that worked.  you should verify this on
your cable, of course.

that should be enough to get a headless box running a serial console.
if you don't want to have a serial console either, you'll need some
kernel changes.  (darrin, can these go in the tree?)

then, don't define ZS_CONSOLE_ABORT in your kernel config file, and the
next will happily boot.  (presumably you'll telnet in or somesuch.)  if
ZS_CONSOLE_ABORT is defined, then you'll drop into DDB if the serial
cable isn't present, which makes it difficult to use multiple machines.

Index: files.next68k
===================================================================
RCS file: /src/cvsroot-netbsd/netbsd/src/sys/arch/next68k/conf/files.next68k,v
retrieving revision 1.7
diff -c -c -r1.7 files.next68k
*** files.next68k	1999/03/23 16:31:15	1.7
--- files.next68k	1999/03/25 16:51:43
***************
*** 9,14 ****
--- 9,15 ----
  
  # serial console options
  defopt opt_serial.h FORCE_SERIAL_CONSOLE
+ defopt opt_serial.h ZS_CONSOLE_ABORT
  
  device mainbus { }
  attach mainbus at root
***************

also, zs.c needs to be patched.  i can't really generate a clean patch
right now, but just replace zs_abort() with the following:

/*
 * Handle user request to enter kernel debugger.
 */
void
zs_abort(cs)
	struct zs_chanstate *cs;
{
	register volatile struct zschan *zc = zs_conschan;
	int rr0;

#include "opt_serial.h"
#if defined(ZS_CONSOLE_ABORT)
	/* Wait for end of break to avoid PROM abort. */
	/* XXX - Limit the wait? */
	do {
		rr0 = zc->zc_csr;
		ZS_DELAY();
	} while (rr0 & ZSRR0_BREAK);

#if defined(KGDB)
	zskgdb(cs);
#elif defined(DDB)
	Debugger();
#else
	printf("stopping on keyboard abort\n");
	callrom();
#endif
#else /* !ZS_CONSOLE_ABORT */
	return;
#endif
}

matt
-- 
matt debergalis <deberg@mit.edu> KB1CTH
finger deberg@ai.mit.edu for PGP key