[9fans] Installation,Step 3b

[9fans] Installation,Step 3b

[Thomas]

After the file server comes up, but before the authentication server is
created I understand:

  1. "none" is the only user the file server will recognize

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


 In the statement in 'Documents' saying r 4000 (how about r4400?) is
supported as  a terminal, 'supported' means with the aid of two other
machines, a file server  and an cpu&authentication server.


  Comments/suggestions on these understandings
  much appreciated
 Tom west

[9fans] Installation,Step 3b

[Steve]

The boddle is at ftp://ftp.ecf.toronto.edu/pub/plan9/steve/indy.bod
It works on the SGI Indy R4000 SC.

forsyth@caldo.demon.co.uk wrote:
> steve kotsopoulos 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.

[9fans] Installation,Step 3b

[forsyth]

>>  1. "none" is the only user the file server will recognize

`users default' adds a few more users, and in `allow' mode
you can attach from a terminal without an auth server
and set things up as you like.

>>bootp functionality resides only in the auth server.

any machine can run it, although it's normally run by a cpu server.
that needn't be an auth server as well, but probably would be for small
installations.  at home, i boot my Indigo cpu/auth server from its
local disc, using /sys/src/boot/indigo; at work, i boot an Indy cpu
server using the Indy's normal boot support, from a file /9indycpu
on the Indy's EFS root partition.  they prompt for the IP data.
both machines then run the bootp and tftp services to
boot my (our) PC terminals.

[9fans] Installation,Step 3b

[forsyth]

>>  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.