Re: Getting started netbooting a NeXTcube

I've now tested versions of "boot" from various releases over the
years.  Above 1.6.2 I get a different result, though not much better:
Pic: https://imgur.com/Cv2FhUX

It says "type 8, non-turbo" and then panics.  Fwiw, my NeXTcube is a turbo.

I do have a NextDimension board in the cube and it's driving the boot
display.  Since NextDimensions were never supported that may be the
problem...  Maybe I'll need to pull it out of the cube to make further
progress here.

Dave


On Tue, Sep 28, 2021 at 3:19 PM David Ross <[email protected]> wrote:
>
> Ok so I've now been able to load the "boot" file via TFTP.  Once
> loaded, I get "en: tx not ready" looping on the console.  I also have
> NFS set up to serve the kernel, but I don't see a mount attempt.
> (I've tested the NFS server from a separate machine and I do see the
> mount in that case.)
>
> Taking a look at the "boot" binary, I was able to find the "en: tx not
> ready" string.  Anyone know where the source for "boot" lives?  Here's
> the binary: http://archive.netbsd.org/pub/NetBSD-archive/NetBSD-1.6.2/nex=
t68k/installation/
>
> Dave
>
> On Sun, Sep 26, 2021 at 9:38 PM David Ross <[email protected]> wrot=
e:
> >
> > Thank you for those words of encouragement...  Turns out it works just
> > as you said!
> > Pic: https://twitter.com/randomdross/status/1442341255845875716
> >
> > And as a bonus, looks like it enables networking in NeXTSTEP as well.
> >
> > Dave
> >
> > On Sun, Sep 26, 2021 at 7:22 PM Brian Willoughby
> > <[email protected]> wrote:
> > >
> > > Hi David,
> > >
> > > When I was learning about how NEXTSTEP networking "works," I remember=
 being very confused about BOOTP. It's entirely possible that my confusion =
was entirely due to lack of knowledge of TCP/IP and networking itself, but =
I do seem to recall some weird behavior that sounds like the race condition=
s you're describing.
> > >
> > > I say go for it: Set up a BOOTP server and then see what happens. It'=
s entirely possible that the race condition is a separate issue. But it's a=
lso possible that's normal behavior and the NeXT will take a different path=
 if it receives a prompt reply to its BOOTP request.
> > >
> > > Brian
> > >
> > >
> > > On Sep 26, 2021, at 18:23, David Ross <[email protected]> wrote=
:
> > > > Hey Brian,
> > > >
> > > > Thanks for that response, and it's great to know there are still
> > > > people hanging out on this list.  =3D)
> > > >
> > > > The next thing I was going to try (and probably will try in any eve=
nt)
> > > > is in fact to set up a BOOTP server.  The reason I didn't go do tha=
t
> > > > yet is only because the strange behavior I'm seeing from the NeXTcu=
be
> > > > makes me think it won't work.  To me, it looks like a kind of a rac=
e
> > > > condition, where the link is only up for a very short period of tim=
e,
> > > > and during that time, a BOOTP packet _might_ make it out.  When
> > > > booting with "ben" I will see a BOOTP packet sometimes, but it's qu=
ite
> > > > inconsistent.  And then I see the link immediately go down.  In fac=
t,
> > > > in some cases it appears the link never even turns on at all.  Mayb=
e
> > > > there's some setting configured that could cause this?
> > > >
> > > > My thinking is that I could have a BOOTP server responding to the
> > > > BOOTP packet, but then the link will still go down regardless.  And=
 it
> > > > won't even work half the time because the BOOTP packet doesn't alwa=
ys
> > > > go out.
> > > >
> > > > If anyone has free time and a NeXT handy, here's what might help a =
bit:
> > > > 1)  Plug in an empty ethernet network switch into the NeXT, just to
> > > > observe if the link LED turns on.
> > > > 2)  Boot into the ROM monitor using Command-`
> > > > 3)  Type "ben" to boot from the network.
> > > > 4)  Observe what gets displayed on the console.  Also, does the lin=
k
> > > > light on the ethernet switch turn on?  And if so, does it stay on o=
r
> > > > turn off after a second or two?
> > > >
> > > > Dave
> > > >
> > > > On Sun, Sep 26, 2021 at 6:05 PM Brian Willoughby <brianw@audiobansh=
ee.com> wrote:
> > > >>
> > > >> Hi David,
> > > >>
> > > >> When booting from disk, BOOTP is a critical step to getting on the=
 network, and things like NetInfo won't even work without it.
> > > >>
> > > >> However, I'm not sure what happens if there isn't a BOOTP response=
. I assume that the NEXTSTEP OS on disk would still launch, but the network=
 would not function, and all configuration from NetInfo would necessarily b=
e absent.
> > > >>
> > > >> Since netboot has no disk to fall back on, I'm going to assume tha=
t BOOTP is absolutely essential to get working before the netboot can even =
begin.
> > > >>
> > > >> I became very familiar with BOOTP while creating my own multi-tier=
 NetInfo hierarchy of NeXTcube, NeXTstation, and even SPARCstation machines=
. Some of the information is duplicated on multiple machines in case one ma=
chine goes down, because things won't boot if the BOOTP server is down. Obv=
iously, I had to toss all that knowledge and learn DHCP with newer systems.=
 I seem to recall that DHCP is a superset of BOOTP, and it might even be tr=
ue that some or all DHCP servers have the ability to respond to BOOTP reque=
sts.
> > > >>
> > > >> I have very little knowledge of netboot, but I would recommend tha=
t you set up a BOOTP server in conjunction / coordination with the netboot =
server. Once the machine receives a BOOTP response, it will probably then c=
ontinue on to load the OS from the netboot server.
> > > >>
> > > >> Just remember: NEXTSTEP is older than DHCP, and certainly older th=
an ZeroConf (Bonjour).
> > > >>
> > > >> Brian
> > > >>
> > > >>
> > > >> On Sep 26, 2021, at 15:53, David Ross <[email protected]> wr=
ote:
> > > >>> Hey port-next68k,
> > > >>>
> > > >>> I've managed to acquire a NeXTcube and I'm playing around with ge=
tting
> > > >>> the old netbsd port up and running on it.  Since it was only ever=
 set
> > > >>> up to netboot, I'm starting there.  Unfortunately I'm seeing some
> > > >>> really weird behavior...
> > > >>>
> > > >>> The ethernet network connection seems to work fine.  When I boot =
up
> > > >>> via the hard drive, I see it recognizes when it's plugged in and
> > > >>> attempts to retrieve network configuration.  Sniffing on the netw=
ork I
> > > >>> see BOOTP packets.
> > > >>>
> > > >>> However, when I attempt to netboot from the ROM monitor, I'm seei=
ng
> > > >>> that the network only comes up for a brief period of time, if at =
all.
> > > >>> During that time, in some cases a BOOTP packet manages to make it=
 out.
> > > >>> I haven't gone any further to try to respond to the BOOTP packet =
yet.
> > > >>>
> > > >>> Any idea what might be causing this behavior, or how it might be
> > > >>> fixed?  Can anyone attest to what the normal behavior is when
> > > >>> netbooting?  (I'd expect the network comes up & stays up, and BOO=
TP
> > > >>> packets continue to get sent on some interval until there's a
> > > >>> response.)
> > > >>>
> > > >>> David Ross
> > > >>> [email protected]
> > > >>>
> > > >>
> > > >
> > >