linux 2.4 and Indy

linux 2.4 and Indy

[Jorik Jonker]

Hi,

I'm having big trouble getting linux 2.4.* to work on my SGI Indy. I want to
use my indycam, and thus compile a kernel with support for that. The problem
is that all the kernels I built do boot, but freeze some moments after
starting the init process. The only kernels that do not have this problem are 
2.4.16 and 2.4.17, but they do not have proper VINO support (they lack the
i2c algo-sgi part).
Is there some patch flying around to fix this, or do I just have bad luck?

/proc/cpuinfo:
system type             : SGI Indy
processor               : 0
cpu model               : R4600 V1.0  FPU V0.0
BogoMIPS                : 99.73
byteorder               : big endian
wait instruction        : yes
microsecond timers      : yes
extra interrupt vector  : no
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available

cheers,
-- 
Jorik Jonker
http://boeventronie.net/

Re: linux 2.4 and Indy

[Kumba]

Jorik Jonker wrote:
> Hi,
> 
> I'm having big trouble getting linux 2.4.* to work on my SGI Indy. I want to
> use my indycam, and thus compile a kernel with support for that. The problem
> is that all the kernels I built do boot, but freeze some moments after
> starting the init process. The only kernels that do not have this problem are 
> 2.4.16 and 2.4.17, but they do not have proper VINO support (they lack the
> i2c algo-sgi part).
> Is there some patch flying around to fix this, or do I just have bad luck?

Check out a cvs tree no later than 12/11/2003, a change in CVS after 
that date seems to have nuked r4k kernels.  It is believed the change in 
question is:

http://www.linux-mips.org/archives/linux-cvs/2003-12/msg00031.html

I've not yet been able to find a 'clean' way to remove the changes to 
those specific files in that commit while keeping all the changes made 
afterwards intact to test this idea.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

Re: linux 2.4 and Indy

[Jorik Jonker]

On Thu, Jan 29, 2004 at 05:40:34AM -0500, Kumba wrote:
> >The problem
> >is that all the kernels I built do boot, but freeze some moments after
> >starting the init process. The only kernels that do not have this problem 
> >are 2.4.16 and 2.4.17, but they do not have proper VINO support (they lack 
> >the i2c algo-sgi part).
> >Is there some patch flying around to fix this, or do I just have bad luck?
> 
> Check out a cvs tree no later than 12/11/2003, a change in CVS after 
> that date seems to have nuked r4k kernels.  It is believed the change in 
> question is:

Hmm, that's strange, I believe that should do the trick, but when I checkout
a tree (cvs -z3 -d:.. co -r linux_2_4 -D 'December 10 2003' linux), I still
get a 'half-booting' kernel. Shall I try to checkout an even older one, until
something is starting to work, or is something else going wrong?

cheers,
-- 
Jorik Jonker
http://boeventronie.net/

Re: linux 2.4 and Indy

[Dominik 'Rathann' Mierzejewski]

On Fri, Jan 30, 2004 at 11:59:03AM +0100, Jorik Jonker wrote:
[...]
> Hmm, that's strange, I believe that should do the trick, but when I checkout
> a tree (cvs -z3 -d:.. co -r linux_2_4 -D 'December 10 2003' linux), I still
> get a 'half-booting' kernel. Shall I try to checkout an even older one, until
> something is starting to work, or is something else going wrong?

I have a working 5th December 2003 kernel running on R4600 V2.0, but since
there were no changes between 5th and 11th December, I'd suspect that yours
should boot fine, too. Did you check if the files you checked out are really
not later than 11th December?

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

Re: linux 2.4 and Indy

[Jorik Jonker]

On Fri, Jan 30, 2004 at 12:12:56PM +0100, Dominik 'Rathann' Mierzejewski wrote:
[...]
> > Hmm, that's strange, I believe that should do the trick, but when I checkout
> > a tree (cvs -z3 -d:.. co -r linux_2_4 -D 'December 10 2003' linux), I still
> > get a 'half-booting' kernel. Shall I try to checkout an even older one, until
> > something is starting to work, or is something else going wrong?
> 
> I have a working 5th December 2003 kernel running on R4600 V2.0, but since
> there were no changes between 5th and 11th December, I'd suspect that yours
> should boot fine, too. Did you check if the files you checked out are really
> not later than 11th December?

I am really sure. The exact command used to checkout my tree was:

# cvs -z3 -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co \
	-D '5 Dec 2003' \
	-r linux_2_4 linux

I am not extremely confident about my CVS skills, but the fine manual tought
me this. I even checked out kernels from June 4th 2003, without success. I am 
now trying February 4th 2003.

cheers,
-- 
Jorik Jonker
http://boeventronie.net/

Re: linux 2.4 and Indy

[Jorik Jonker]

On Fri, Jan 30, 2004 at 09:49:11PM +0100, Jorik Jonker wrote:
> # cvs -z3 -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co \
> 	-D '5 Dec 2003' \
> 	-r linux_2_4 linux
> 
> I am not extremely confident about my CVS skills, but the fine manual tought
> me this. I even checked out kernels from June 4th 2003, without success. I am 
> now trying February 4th 2003.

Without success again.. I am beginning to suspect that I am doing something
completely wrong. I must say I am building using a crosscompiler:
mips-linux-gcc (GCC) 3.2.3 20030221 (Debian prerelease), but.. I successfully
produced a working 2.4.16 and 2.4.17. I am now going to do a native '5
december' build, hoping that will solve the problems.

-- 
Jorik Jonker
http://boeventronie.net/

Re: linux 2.4 and Indy

[Ralf Baechle]

On Thu, Jan 29, 2004 at 05:40:34AM -0500, Kumba wrote:

> Check out a cvs tree no later than 12/11/2003, a change in CVS after 
> that date seems to have nuked r4k kernels.  It is believed the change in 
> question is:
> 
> http://www.linux-mips.org/archives/linux-cvs/2003-12/msg00031.html
> 
> I've not yet been able to find a 'clean' way to remove the changes to 
> those specific files in that commit while keeping all the changes made 
> afterwards intact to test this idea.

Over the past days a few fixes went into CVS, the last only a few minutes
ago.  Can you retry and let me know?

  Ralf

Re: linux 2.4 and Indy

[Jorik Jonker]

On Sat, Jan 31, 2004 at 04:04:35AM +0100, Ralf Baechle wrote:
> Over the past days a few fixes went into CVS, the last only a few minutes
> ago.  Can you retry and let me know?

Well, it a little 'better'. It now hangs while configurating the network
device, while in earlier versions the freeze appeared while calibrating the
delay loop, or mounting the root fs.
Is there something else I could try?
Until I know what's going on, I am going to look for a kernel with proper
VINO support which is 'old' enough to run without the freeze..

cheers,
-- 
Jorik Jonker
http://boeventronie.net/

R4600 V1.7 errata

[Ralf Baechle]

On Sat, Jan 31, 2004 at 03:10:27PM +0100, Jorik Jonker wrote:

> 
> On Sat, Jan 31, 2004 at 04:04:35AM +0100, Ralf Baechle wrote:
> > Over the past days a few fixes went into CVS, the last only a few minutes
> > ago.  Can you retry and let me know?
> 
> Well, it a little 'better'. It now hangs while configurating the network
> device, while in earlier versions the freeze appeared while calibrating the
> delay loop, or mounting the root fs.
> Is there something else I could try?
> Until I know what's going on, I am going to look for a kernel with proper
> VINO support which is 'old' enough to run without the freeze..

Seems I lost the R4600 V1.7 errata documents I used to have so all
information that is left to me is what's documented in the Linux code.
I've removed all the mentioned instructions and the kernel which
otherwise is running fine on R5000 systems or R4600 V2.0 keeps crashing.
I suspect I'm becoming victim of some of the other of the chip's errata;
it has at least 18 ...

Anybody still got errata information for the R4600 V1.7 around?

  Ralf

Re: R4600 V1.7 errata

[Ralf Baechle]

On Sun, Feb 01, 2004 at 05:52:58AM +0100, Ralf Baechle wrote:

> > Well, it a little 'better'. It now hangs while configurating the network
> > device, while in earlier versions the freeze appeared while calibrating the
> > delay loop, or mounting the root fs.
> > Is there something else I could try?
> > Until I know what's going on, I am going to look for a kernel with proper
> > VINO support which is 'old' enough to run without the freeze..
> 
> Seems I lost the R4600 V1.7 errata documents I used to have so all
> information that is left to me is what's documented in the Linux code.
> I've removed all the mentioned instructions and the kernel which
> otherwise is running fine on R5000 systems or R4600 V2.0 keeps crashing.
> I suspect I'm becoming victim of some of the other of the chip's errata;
> it has at least 18 ...
> 
> Anybody still got errata information for the R4600 V1.7 around?

Jorik was so friendly to track down the patch in CVS that broke the R4600
V1.7 back in time.  With that as a start it was fairly easy to isolate the
problem further.  Seems we became victim of some erratum that affects the
operation of indexed I-cache flushes only.  Last night I commited a patch
that provides an optimized solution for the problem.

Still, knowing the errata sheet of this processor has at least 18 items
on it I'd not place bets on it being totally reliable.  Therefore I'm
still interested, just in case somebody happens to run over a dusty errata
sheet somewhere :-)

  Ralf

Re: R4600 V1.7 errata

[Dominik 'Rathann' Mierzejewski]

On Tue, Feb 03, 2004 at 12:39:28PM +0100, Ralf Baechle wrote:
[...] 
> Jorik was so friendly to track down the patch in CVS that broke the R4600
> V1.7 back in time.  With that as a start it was fairly easy to isolate the
> problem further.  Seems we became victim of some erratum that affects the
> operation of indexed I-cache flushes only.  Last night I commited a patch
> that provides an optimized solution for the problem.

I assume it's safe to test it now? I'll build it for my R4600 V2.0 and
report in a while. Stay tuned.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

Re: R4600 V1.7 errata

[Ralf Baechle]

On Tue, Feb 03, 2004 at 12:42:53PM +0100, Dominik 'Rathann' Mierzejewski wrote:

> On Tue, Feb 03, 2004 at 12:39:28PM +0100, Ralf Baechle wrote:
> [...] 
> > Jorik was so friendly to track down the patch in CVS that broke the R4600
> > V1.7 back in time.  With that as a start it was fairly easy to isolate the
> > problem further.  Seems we became victim of some erratum that affects the
> > operation of indexed I-cache flushes only.  Last night I commited a patch
> > that provides an optimized solution for the problem.
> 
> I assume it's safe to test it now? I'll build it for my R4600 V2.0 and
> report in a while. Stay tuned.

2.0 requires different workarounds which are already in place and functional
since quite some time.  We still lacking a fix for one important erratum of
the 2.0 but it seems pretty stable without.

Chip revs later than 2.0 do identify as 2.0 so if you're lucky your processor
is actually a post-2.0 and working just fine ...

  Ralf

Re: R4600 V1.7 errata

[Maciej W. Rozycki]

On Tue, 3 Feb 2004, Ralf Baechle wrote:

> 2.0 requires different workarounds which are already in place and functional
> since quite some time.  We still lacking a fix for one important erratum of
> the 2.0 but it seems pretty stable without.

 Well, I can actually see two problems: #4 that is fairly easy to handle
and #7 which is painful and which is unfortunately present with the R4700
as well.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: R4600 V1.7 errata

[Ralf Baechle]

On Tue, Feb 03, 2004 at 04:43:19PM +0100, Maciej W. Rozycki wrote:

> > 2.0 requires different workarounds which are already in place and functional
> > since quite some time.  We still lacking a fix for one important erratum of
> > the 2.0 but it seems pretty stable without.
> 
>  Well, I can actually see two problems: #4 that is fairly easy to handle
> and #7 which is painful and which is unfortunately present with the R4700
> as well.

If #7 would only affect the R4700 the world would peachy ...  To my
knowledge the dusty box here in a corner is the only R4700 that ever ran
Linux ...

Under a different bug number this bug also affects the R4600 V1.x; it's
fixed in post-2.0 R4600 (which all identify as 2.0) and post-1.1 R4700.
Since a workaround may be a bit performance sensitive I think I'll try if
it can be probed for reliably.

  Ralf

Re: R4600 V1.7 errata

[Maciej W. Rozycki]

On Tue, 3 Feb 2004, Ralf Baechle wrote:

> Under a different bug number this bug also affects the R4600 V1.x; it's
> fixed in post-2.0 R4600 (which all identify as 2.0) and post-1.1 R4700.
> Since a workaround may be a bit performance sensitive I think I'll try if
> it can be probed for reliably.

 The conditions appear clear, so they may be quite easy to reproduce for
the erratum to trigger.  I guess you may take the optimization hint from
the document into account as well.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: R4600 V1.7 errata

[Dominik 'Rathann' Mierzejewski]

On Tue, Feb 03, 2004 at 12:42:53PM +0100, Dominik 'Rathann' Mierzejewski wrote:
[...]
> I assume it's safe to test it now? I'll build it for my R4600 V2.0 and
> report in a while. Stay tuned.

Works now. Thanks, guys.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

Re: R4600 V1.7 errata

[Pete Popov]

On Wed, 2004-02-04 at 07:48, Dominik 'Rathann' Mierzejewski wrote:
> On Tue, Feb 03, 2004 at 12:42:53PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> [...]
> > I assume it's safe to test it now? I'll build it for my R4600 V2.0 and
> > report in a while. Stay tuned.
> 
> Works now. Thanks, guys.

The latest cache updates break the Au1x kernel. I don't know yet exactly
what the problem is, but I tested with a snapshot before and after the
updates.

Pete

Re: R4600 V1.7 errata

[Ralf Baechle]

On Wed, Feb 04, 2004 at 07:59:49AM -0800, Pete Popov wrote:

> > [...]
> > > I assume it's safe to test it now? I'll build it for my R4600 V2.0 and
> > > report in a while. Stay tuned.
> > 
> > Works now. Thanks, guys.
> 
> The latest cache updates break the Au1x kernel. I don't know yet exactly
> what the problem is, but I tested with a snapshot before and after the
> updates.

The cache updates should specifically only affects systems that explicitly
enable the cache workaround in <asm/war.h>; for any other the compiler
should totally eleminate the workaround from the binary.

Therefore my first guess would be pg-r4k.c.

  Ralf