IP30 goes relatively far now

IP30 goes relatively far now

[Stanislaw Skowronek]

Hello,

I'm currently doing a reverse-engineered IP30 port of Linux-MIPS.
Currently I'm using 2.6.1 as my base.

I don't know if it's been already fixed in >2.6.1, but in genex.S there
should be a 'nop' between 'jal do_\handler' and 'ret_from_exception'. The
symptom is a hang on 'Checking for the daddi bug...'. Somebody apparently
got used to '.set reorder' :P

Well, now the kernel crashes a bit later. Actually, it gets to 'mice: PS/2
mouse device common for all mice' and then gets an Instruction bus error.
I will look into this.

Currently the kernel supports only MGRAS graphics (SI, SSI, MXI, SE, SSE,
MXE) and uniprocessor. I don't have a SMP machine here, but I guess it
would not be particularly hard to do. The ODYSSEY (VPro) would be a bit
harder, as its architecture is vastly different from the MGRAS. Anyone
interested may send me a VPro6 ;)

When I get to 'cannot mount root', I will release the kernel patch.

Yours,

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.

Re: IP30 goes relatively far now

[Florian Laws]

On Fri, Apr 16, 2004 at 11:13:29PM +0200, Stanislaw Skowronek wrote:
> 
> Currently the kernel supports only MGRAS graphics (SI, SSI, MXI, SE, SSE,
> MXE) and uniprocessor. I don't have a SMP machine here, but I guess it
> would not be particularly hard to do. The ODYSSEY (VPro) would be a bit
> harder, as its architecture is vastly different from the MGRAS. Anyone
> interested may send me a VPro6 ;)

Aren't the SI, MXI very similiar to the IMPACT graphic boards of the
Indigo2 machines? If so, this might be interesting for IP22/29 as well.

Regards,

Florian

Re: IP30 goes relatively far now

[Maciej W. Rozycki]

On Fri, 16 Apr 2004, Stanislaw Skowronek wrote:

> I don't know if it's been already fixed in >2.6.1, but in genex.S there
> should be a 'nop' between 'jal do_\handler' and 'ret_from_exception'. The
> symptom is a hang on 'Checking for the daddi bug...'. Somebody apparently
> got used to '.set reorder' :P

 The bug is elsewhere -- there's an incorrect extraneous ".set push" in
the file.  I'll commit a fix immediately.

 Thanks for the report.

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

Re: IP30 goes relatively far now

[Maciej W. Rozycki]

On Fri, 16 Apr 2004, Maciej W. Rozycki wrote:

> > I don't know if it's been already fixed in >2.6.1, but in genex.S there
> > should be a 'nop' between 'jal do_\handler' and 'ret_from_exception'. The
> > symptom is a hang on 'Checking for the daddi bug...'. Somebody apparently
> > got used to '.set reorder' :P
> 
>  The bug is elsewhere -- there's an incorrect extraneous ".set push" in
> the file.  I'll commit a fix immediately.

 I must have been blind -- there's a matching ".set pop" elsewhere.  Is a 
"nop" really missing in the output?  I've assembled the file and I can't 
see any problem:

000000000000022c <handle_daddi_ov_int>:
 22c:	0c000000 	jal	0 <except_vec0_generic>
			22c: R_MIPS_26	do_daddi_ov
			22c: R_MIPS_NONE	*ABS*
			22c: R_MIPS_NONE	*ABS*
 230:	03a0202d 	move	a0,sp
 234:	08000000 	j	0 <except_vec0_generic>
			234: R_MIPS_26	ret_from_exception
			234: R_MIPS_NONE	*ABS*
			234: R_MIPS_NONE	*ABS*
 238:	00000000 	nop
 23c:	00000000 	nop

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

Re: IP30 goes relatively far now

[Stanislaw Skowronek]

>  I must have been blind -- there's a matching ".set pop" elsewhere.  Is a 
> "nop" really missing in the output?  I've assembled the file and I can't 
> see any problem:
> 
> 000000000000022c <handle_daddi_ov_int>:
>  22c:	0c000000 	jal	0 <except_vec0_generic>
> 			22c: R_MIPS_26	do_daddi_ov
> 			22c: R_MIPS_NONE	*ABS*
> 			22c: R_MIPS_NONE	*ABS*
>  230:	03a0202d 	move	a0,sp
>  234:	08000000 	j	0 <except_vec0_generic>
> 			234: R_MIPS_26	ret_from_exception
> 			234: R_MIPS_NONE	*ABS*
> 			234: R_MIPS_NONE	*ABS*
>  238:	00000000 	nop
>  23c:	00000000 	nop

Oooh, it's SOOO strange!

For me, it is:

   ...
 228:   03a0202d        move    a0,sp
 22c:   0c000000        jal     0 <except_vec0_generic>
                        22c: R_MIPS_26  do_daddi_ov
                        22c: R_MIPS_NONE        *ABS*
                        22c: R_MIPS_NONE        *ABS*
 230:   08000000        j       0 <except_vec0_generic>
                        230: R_MIPS_26  ret_from_exception
                        230: R_MIPS_NONE        *ABS*
                        230: R_MIPS_NONE        *ABS*

because the last '.set *reorder' before is in 'nmi_handler', and it is a
'.set noreorder'. I will get a newer kernel (I did 2.6.1 because it worked
for me, and 2.6.3 crashed on my PC with astonishing frequency, so I didn't
want to take a chance) and check.

Anyway, the procedure is 'handle_daddi_ov' and not 'handle_daddi_ov_int'
in my genex.S, and it's substantially longer than your code. Do you have
the SAVE_ALL there? I don't see it.

Yours,

Stanislaw Skowronek

Re: IP30 goes relatively far now

[Maciej W. Rozycki]

On Sat, 17 Apr 2004, Stanislaw Skowronek wrote:

> because the last '.set *reorder' before is in 'nmi_handler', and it is a
> '.set noreorder'. I will get a newer kernel (I did 2.6.1 because it worked

 Ouch -- there used to be such a bug in the past, but it was fixed on Aug
6th, 2003.  Please update indeed -- your snapshot is severly old and there
have been plenty updates since then, so chances are you may struggle with
problems that have been dealt with elsewhere, too.  Please use the CVS, of
course.

> for me, and 2.6.3 crashed on my PC with astonishing frequency, so I didn't
> want to take a chance) and check.

 Well, the stability of the i386 and the MIPS port for a given version is
sometimes unrelated. ;-)

> Anyway, the procedure is 'handle_daddi_ov' and not 'handle_daddi_ov_int'
> in my genex.S, and it's substantially longer than your code. Do you have
> the SAVE_ALL there? I don't see it.

 I've stripped the preceding unrelated entry code.  The "_int" alternate
entry points to exception handlers were merged from 2.4 on Jan 3th (only
handle_fpe_int is actually needed, for R3k-class CPUs, as they handle the
FP error as an ordinary interrupt).

  Maciej

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

Re: IP30 goes relatively far now (photos)

[Stanislaw Skowronek]

For the little unbeliever in all of us:

http://www.et.put.poznan.pl/~sskowron/ip30/

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.

Re: IP30 goes relatively far now (photos)

[Kumba]

Stanislaw Skowronek wrote:
> For the little unbeliever in all of us:
> 
> http://www.et.put.poznan.pl/~sskowron/ip30/
> 
> Stanislaw Skowronek

All I'll say is that SGI Logo in the background of the console is 
*awesome* :)

Think the driver for the Octane console is gonna be usable for the 
Impact cards on the Indigo2?


--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: IP30 goes relatively far now (photos)

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Sat, Apr 17, 2004 at 06:50:59AM +0200, Stanislaw Skowronek wrote:
> For the little unbeliever in all of us:
> http://www.et.put.poznan.pl/~sskowron/ip30/
Really nice, esp. the 1GB of ram in there and the logo ;-).

What CPU is in your octane tho? I've got access to an R12k Octane that
could be ripe for linux if R10/12k is ever made to work (I'm waiting for
a book from Barnes+Noble so I can try to do an O2 R12k).

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]