From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat,  6 Dec 1997 12:59:27 +0000
From: forsyth@caldo.demon.co.uk forsyth@caldo.demon.co.uk
Subject: [9fans] Installation,Step 3b
Topicbox-Message-UUID: 6c533c2e-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19971206125927.oCKgQTrlmmERLrQZOuiAeZl03YSqCIZIhB42ixtZylE@z>

>>  2. An indy r4400 cannot be booted from the file server using bootp because
>>bootp functionality resides only in the auth server.

Indys aren't supported by the CD in any form, only
the older Indigo R3k and R4k (most models).
someone significant wrt the Indy at SGI agreed to get the information
to me (legitimately) so i could do a cpu/terminal kernel port, but he
was moved within the company, and his successors were unhelpful.

steve kotsopoulis has made some changes (in boddle form somewhere)
to allow some model of Indy with secondary cache
to work as a CPU server, based on the /sys/src/9/chm
(challenge M) kernel.  i made a few more changes to get my
R4600 Indy (no secondary cache) to work, and i use it as a cpu server.
i also looked at reverse engineering the operation of
the Indy graphics chip, to complete a usable terminal port,
but had other things to do.  it didn't look very hard to do
basic support along the lines of /sys/src/9/indigo4k, provided
there weren't any hidden bits to twiddle to enable things.
on the other hand, i thought i might not be able to get the Indy audio and video
subsystems going and those were the ones that most interested
me at the time.  eventually it was easier to switch to the
Intel architecture -- ugly, certainly clunkier, and with a stupid
processor architecture -- but where at least some of the companies
publish data books or data sheets some of the time.  one still runs up
against register-level secrecy on the PC platform for some cards,
but there is usually at least one usable card for which programming
data is available.