>[1] Its not entirely headless, as the bootblocks don't seem to work with
>    -DSERIAL. Is anybody currently using -DSERIAL in their bootblocks?

Yes, but it was painful to get working.    -DSERIAL uses the BIOS interrupt
0x14 for serial I/O, and the BIOS seems to have more strict cable 
requirements than the NetBSD kernel COMCONSOLE code does.   I found 
that with my simple pin "2,3,7" cable that the BIOS I/O calls were
failing with the "time-out" bit set in the Transmit Status byte.

After making a new cable with more pins on it, -DSERIAL started working.


on a related note, there is a bad interaction [i.e. bug] between kernel 
printf's and normal serial I/O.    for example, if you put debugging kernel 
printf's in the networking code, and then run "telnet" on the console
it will print:

clouseau[654]> telnet 128.252.200.1
Trying 128.252.2<KERNEL PRINTFs APPEAR HERE>
<console output HANGS here, until you strike a key on the serial console>
00.1...

Since strlen("Trying 128.252.2") == 16, I figure there is a 16 byte
buffer around somewhere.    That leads my guess about the following 
string of events:

1. "telnet" does write(1, "Trying 128.252.200.1...\n", 24) to serial
	console
2. com.c gets the 24 bytes chunk from the write system call and starts
	output on the first 16 byte chunk ["Trying 128.252.2"], and then 
	sleeps awaiting for the I/O operation to finish
3. "telnet" continues and does a connect(), which causes TCP to get called
4. my debug printf's in the TCP code print, changing the state of the serial
	chip (i.e. the interrupt that com.c is waiting for gets cleared)
5. connect finishes
6. com.c can't start the next 16 byte chunk ("00.1...\n") because it is
	waiting for an interrupt that never will happen [because the kernel
	printf cleared it]
7. i get tired of waiting, and strike a key, which generates an interrupt
	and kicks the com.c state machine back into action and "00.1...\n"
	gets printed.

chuck