Subject: Task list --preliminary list

From: Miguel de Icaza <[email-masked]>
Date: Mon, 22 Sep 1997 21:32:19 -0500

Here is a preliminary task list of things that should be done for a
complete Linux/MIPS port, right now it includes by personal favorites
and I am working on some of those bits, but some of the other can be
done now, I have a copy of this at:

	http://www.nuclecu.unam.mx/~miguel/mips-task-list.txt

Priority: 

[9]  Get more userland programs compiled in RPM form

[9]  Merging the latest GNU libc releases.

[9]  Get the X libraries compiled.

[5]  Getting SGI mouse to work.

[5]  Test the STREAMS implementation of the mouse.

[6]  Figure why init is setting the sigprocmask to a value different
     from 0.  This disables the debugger (SIGTRAP is disabled for
     all child processes).

[7]  Getting IRIX X server to accept connections.

Please, send me additions to this list.
Miguel.

---

From: [email-masked] (Ariel Faigon)
Date: Mon, 22 Sep 1997 20:05:26 -0700 (PDT)

My personal favorites are a drudgery to wizards but an essential
necessity for most mortals:

[5] Verify that the latest source tree on Llinus compiles and boots
    (maybe automate this with a daily build that gets tested)
[4] Utility to boot Linux from IRIX (both locally and over net)
[3] Stable precompiled Indy kernel + root-contents on linus
[3] A working HOWTO for booting Linux on Indy

All the above even without having X :-)

:
:
:Here is a preliminary task list of things that should be done for a
:complete Linux/MIPS port, right now it includes by personal favorites
:and I am working on some of those bits, but some of the other can be
:done now, I have a copy of this at:
:
:	http://www.nuclecu.unam.mx/~miguel/mips-task-list.txt
:
:Priority: 
:
:[9]  Get more userland programs compiled in RPM form
:
:[9]  Merging the latest GNU libc releases.
:
:[9]  Get the X libraries compiled.
:
:[5]  Getting SGI mouse to work.
:
:[5]  Test the STREAMS implementation of the mouse.
:
:[6]  Figure why init is setting the sigprocmask to a value different
:     from 0.  This disables the debugger (SIGTRAP is disabled for
:     all child processes).
:
:[7]  Getting IRIX X server to accept connections.
:
:Please, send me additions to this list.
:Miguel.
:

-- 
Peace, Ariel

---

From: Miguel de Icaza <[email-masked]>
Date: Mon, 22 Sep 1997 22:35:49 -0500

>     (maybe automate this with a daily build that gets tested)

I checked this yesterday when I commited my code to linus.

> [4] Utility to boot Linux from IRIX (both locally and over net)

Well, we do not need this, since sash can load the Linux kernel from
both an efs file system and from the network.  I thought this had been
covered in the HOWTO?

	Booting from local disk:

	1. Put your kernel on an EFS partition say, /linux/vmlinux.gz

	2. reset your Indy.

	3. Enter maintenance mode (click on the button before IRIX
	   boots).

	4. at the prompt type:  boot /linux/vmlinux.gz

	Note that I lack a manual on the ARC, so I am limited by what
	I figured would boot the kernel.  There are some very interesting
	variables that allow you to boot the kernel from any file
	system on any partition.
	
> [3] Stable precompiled Indy kernel + root-contents on linus

	I have my stable precompiled Indy kernel, I can setup a cron
	job to upload my latest kernel everyday :-).  They are always
	stable.

	My root contents are currently pretty hosed up, as I have a mixture
	of IRIX, Linux and gnemul + some rpms + some broken rpms + a libc
	that I am not sure it is ok. 

Cheers,
Miguel.

---

From: Eric Kimminau <[email-masked]>
Date: Mon, 22 Sep 1997 23:49:34 -0400

PRI 10
Howto updated so it show how to take a system currently running IRIX and
get it to a point where it is running Linux. I know it isn't truly
development work, but Ive been stuck with a non-functional Indy for most
of a month.My problems seem to be related to trying to NFS boot off of a
remote XFS file system but I could be wrong. I haven't grabbed the
latest kernel to try so that could resolve my issue.

-- 
Eric Kimminau                             System Engineer
[email-masked]                       Silicon Graphics, Inc
Vox:(810) 848-4455                        39001 West 12mile Road
Fax:(810)848-5600                         Farmington, MI 48331-2903
            "I speak my mind and no one else's."
    http://www.dcs.ex.ac.uk/~aba/rsa/perl-rsa-sig.html

-----END PGP PUBLIC KEY BLOCK-----
http://bs.mit.edu:11371/pks/lookup?op=vindex&search=Eric+A.+Kimminau&fingerprint=on

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 22 Sep 1997 21:09:11 -0700 (PDT)

> latest kernel to try so that could resolve my issue.

This issues might have been resolved by Miguel's latest CVS commit.
Your NFS problems might also have been cause by the VFS rewrite which
was essentially turning the filesystems into an inferno for a limited
time.

  Ralf

---

From: Eric Kimminau <[email-masked]>
Date: Tue, 23 Sep 1997 06:48:23 -0400

> was essentially turning the filesystems into an inferno for a limited

Agreed. Im going to re-try boot later this afternoon with the new
kernel.

-- 
Eric Kimminau                           System Engineer/RSA
[email-masked]                     Silicon Graphics, Inc
Voice: (248) 848-4455                   39001 West 12 Mile Rd.
Fax:   (248) 848-5600                   Farmington, MI 48331-2903

                 VNet Extension - 6-327-4455
              "I speak my mind and no one else's."
       http://www.dcs.ex.ac.uk/~aba/rsa/perl-rsa-sig.html

    When confronted by a difficult problem, solve it by reducing 
    it to the question, "How would the Lone Ranger handle this?"

---

From: Mark Salter <[email-masked]>
Date: Tue, 23 Sep 1997 13:37:28 -0500

> I checked this yesterday when I commited my code to linus.

Yes, but I bet you didn't check it on an Indy with no scache :-)
I have one of those beasts and the latest code in the cvs tree
crashes early in the boot process.

The code in arch/mips/mm/r4xx0.c which sets up the cache flush
procs now selects r4k_flush_page_to_ram_d32i32_r4600 where
earlier versions of r4xx0.c selected r4k_flush_page_to_ram_d32i32.
I think the current choice is correct in that my Indy has the
R4600 cache bug mentioned in IDT's errata. But the *_r4600 version
also has some inline assembler under an ifdef CONFIG_SGI which
appears to do something to the SGI scache. But since I have
no scache, I get a bus error irq instead.

It seems a bit strange that r4k_flush_page_to_ram_d32i32_r4600
has this bit of SGI specific code, but r4k_flush_page_to_ram_d32i32
does not. ???

--Mark

---

From: Mike Shaver <[email-masked]>
Date: Tue, 23 Sep 1997 18:32:19 -0400 (EDT)

>     (maybe automate this with a daily build that gets tested)

Boots on?
We'll need to define a set of known-tested/supported systems, at least
for now.

> [4] Utility to boot Linux from IRIX (both locally and over net)

Stay tuned.
I'm going to be incommunicado for about a week while I move to
Mountain View, but I only have one bug[*] keeping me from being able
to boot off of an EFS partition, etc.  That should make things a lot
easier.

[*] Yes, it's embarrassingly true: I still can't get indirect extents
right.  I'll check my code in tomorrow, in case someone smarter than
me wants to take a crack at it.

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>           Resident Linux bigot and kernel hacker. (OOPS!)           
#> `If you get bitten by a bug, tough luck...the one thing I won't do  
#> is feel sorry for you.  In fact, I might ask you to do it all over  
#> again, just to get more information.  I'm a heartless bastard.'     
#>                       -- Linus Torvalds (on development kernels)

---

From: "William J. Earl" <[email-masked]>
Date: Tue, 23 Sep 1997 15:40:35 -0700

> has this bit of SGI specific code, but r4k_flush_page_to_ram_d32i32

     I have not looked at the source, but the problem is probably that
there needs to be two cases, one with and one without Indy R4600 scache.
This is determined by reading out the EEPROM on the CPU board, and looking
at the appropriate bits for "scache present" and "scache size".  The 
processor will get a bus error trying to reference the control registers
of the scache controller (via uncached memory references) if the secondary
cache is not present.

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 24 Sep 1997 01:34:50 +0200 (MET DST)

> has this bit of SGI specific code, but r4k_flush_page_to_ram_d32i32

The R4400 versions of the Indy have the "real" second level cache and
use a SC CPU version.  Opposed to that the  L2 cache of the R4600 and
R5000 Indies is controlled by external circuitry which needs special code.

Actually since we have the same problem on a couple of other machines,
SNI RM family one of them,  what should be done is to break out all the
#ifugly'ed SGI bits and provide some hooks for them.  You L2 less
machine would simply plug an empty function into these hooks.

Using r4k_flush_page_to_ram_d32i32 was definately wrong, the R4600
cache is two way set associative and flush_page_to_ram needs to take
care of that for all the R4600 and R5000 relatives.

  Ralf