From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 20 Oct 1995 05:11:02 -0400
From: John Carmack johnc@idcanon1.idsoftware.com
Subject: nextstation stuff
Topicbox-Message-UUID: 2f100a90-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19951020091102.sYcZpFu62Doakj0rtbUj41pVURmBFRUOX3m92Wk9OtM@z>

I finally got a very old next cube (rom 2.2) to net boot a kernel. =
  It has the video register bug, so it hung immediately after =
startup unless I either booted NEXTSTEP first, or entered

e 2004184
ea
^c

at the monitor by hand.  Adding the=20
> #define VIDEOOUTLIMIT	IO(0x02004184)
> *(ulong*)VIDEOOUTLIMIT =3D 0xea;
patch to the kernel fixed it for automatic startup.

My rom 3.3 systems still choke, and manually setting the pc still =
won't get them going.
It looks like the problem is due to the lack of a unixthread load =
command in the mach header.  I am going to hack l2 and see if I =
can build a kernel that loads properly on all NeXT roms.

Unfortunately, my cube has 16 1meg simms, only 8 megs visible to =
plan9.  8 megs is not enough to relink the kernel in...

Before I decided to wipe the scsi drive for swapping, I tried =
swapping to a file over u9fs.  This caused system traps during =
linking.  I can certainly see how it would fail (part of the u9fs =
client gets swapped out), but the docs say "swap to raw devices or =
remote servers".  Is that supposed to work?

After changing over to 9nextstationdisk and made a real swap =
partitiion, things worked fine, but linking was =
sssslllllooooowwwww.  I ordered 64 megs of ram to fix that =
problem...

I spent a while figring out how to get the proper plan9 bootp =
extension information to the cube.  NeXT's bootpd does not support =
the vendor specific extensions, so I had to compile something =
else.

The bootpd source included with the plan9 cdrom compiled with some =
warnings, but died shortly after starting, so I grabbed the latest =
2.4 bootpd source from the net.  After adding -posix, it compiled =
and linked with no warnings.   I couldn't see a way to enter raw =
text vendor data in the 2.4 bootptab (the vm=3D"text..." format is =
gone), so I wound up just making a gross hack in the source to =
create exactly the packets I want.  I will probably go back and =
make the 2.1 code included on the cd run properly, because that =
can at least be configured properly from the bootptab file.

The initial bootp packet from a net booting NeXT machine will have =
"NeXT" as the vendor id, and the return packet with booting info =
must also have that.  NeXTs also seem to require that the bootfile =
be tftpd from the same system sending the bootp packets.

The bootp info packet from the plan 9 kernel after choosing a tcp =
root will have "p9  " as the vendor id, and you want to return 'p9 =
 255.255.255.0 fileserver_ip 0.0.0.0 gateway_ip" as the vendor =
extension (assuming a type C network and no auth server).

Unfortunately, I had to remove the old cube from the NEXTSTEP =
netinfo database, or the bootpd daemons would both send confusing =
packets.  I don't think the NeXT bootp can't just be replaced, =
because it is intertwined with netinfo.


So, finally, I have things running smoothly the way I want. :-)

I was bummed to find that alef (and hence acme) doesn't exist far =
the '020.

Does cfs work with u9fs?  It wouldn't automatically start up, and =
when I started it manually, it failed as soon as I went into the =
cached directory.

Has anyone made a plan9 system with a >8bit color display?  I =
might try and bring the system up on a color nextstation.


John Carmack
Id Software