[parisc-linux] FB on c3k

[parisc-linux] FB on c3k

[Grant Grundler]

Getting closer.

I'm comfortable that FB ioctl wrappers are ok with an updated
version of the ioctl32.c patch (ftp.p-l.o:patches/fb_ioctl.diff).
"fbset -v -i" on c3k (64-bit kernel, PDC 4.6, Vis-EG/PCI) reports:

Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "1280x1024"
    geometry 1280 1024 1280 1024 8
    timings 0 0 0 0 0 0 0
    rgba 8/0,8/0,8/0,0/0
endmode

Getting further frame buffer information
Frame buffer device information:
    Name        : 
    Address     : 0xfb000000
    Size        : 33554432
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 0
    YPanStep    : 0
    YWrapStep   : 0
    LineLength  : 2048
    MMIO Address: 0xfa100000
    MMIO Size   : 4194304
    Accelerator : No


But when I try to "fbi foo.jpg", I get diagonal black "lines" from
top left to bottom right striped about 3-4 pixels wide and spaced about
12-16 pixels apart (all just guesses). Tux does show up in the top
left corner at boot and stays there. System seems to lock up.
TOC doesn't work. Power off occurs 20-30 seconds after hitting power
button.

I suspect some parameter isn't right for FB device definition
but don't know what. Hoping the diagonal lines are the clue
that someone could tell me about - some sort of "off-by-one"
type of error.

thanks,
grant

Re: [parisc-linux] FB on c3k

[Thomas Bogendoerfer]

On Wed, Mar 06, 2002 at 01:01:01AM -0700, Grant Grundler wrote:
> 
> Getting closer.

right of me is a monitor connected to a B2600 with a X screen on it :-)

> I suspect some parameter isn't right for FB device definition
> but don't know what. Hoping the diagonal lines are the clue
> that someone could tell me about - some sort of "off-by-one"
> type of error.

No jsm is right, the U bit doesn't matter, if we set the right
physical address in the TLB. I really don't understand why it's
needed to supply more than 40bit, but with the patch below X works
(fbi still crashes the machine, but that could be a font problem,
as well). Before I'll commit the change, I'll post it here for
comments.

Thomas.

PS: VIS-EG users, who don't get a clear tux on the screen after startup
should select a non double buffered mode. There's more to do to get it
working in double buffered mode.


Index: entry.S
===================================================================
RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v
retrieving revision 1.90
diff -u -p -r1.90 entry.S
--- entry.S	2002/03/03 23:00:10	1.90
+++ entry.S	2002/03/06 23:13:33
@@ -1045,8 +1045,6 @@ dtlb_miss_20w:
 	space_to_prot   spc prot        /* create prot id from space */
 	depd            pte,8,7,prot    /* add in prot bits from pte */
 
-	extrd,u,*=      pte,_PAGE_NO_CACHE_BIT+32,1,r0
-	depdi		1,12,1,prot
 	extrd,u,*=      pte,_PAGE_USER_BIT+32,1,r0
 	depdi		7,11,3,prot   /* Set for user space (1 rsvd for read) */
 	extrd,u,*= 	pte,_PAGE_GATEWAY_BIT+32,1,r0
@@ -1055,7 +1053,7 @@ dtlb_miss_20w:
 	/* Get rid of prot bits and convert to page addr for idtlbt */
 
 	depdi		0,63,12,pte
-	extrd,u         pte,56,32,pte
+	extrd,u         pte,56,52,pte
 	idtlbt          pte,prot
 
 	rfir
@@ -1124,8 +1122,6 @@ nadtlb_miss_20w:
 	space_to_prot   spc prot        /* create prot id from space */
 	depd            pte,8,7,prot    /* add in prot bits from pte */
 
-	extrd,u,*=      pte,_PAGE_NO_CACHE_BIT+32,1,r0
-	depdi		1,12,1,prot
 	extrd,u,*=      pte,_PAGE_USER_BIT+32,1,r0
 	depdi		7,11,3,prot   /* Set for user space (1 rsvd for read) */
 	extrd,u,*= 	pte,_PAGE_GATEWAY_BIT+32,1,r0
@@ -1134,7 +1130,7 @@ nadtlb_miss_20w:
 	/* Get rid of prot bits and convert to page addr for idtlbt */
 
 	depdi		0,63,12,pte
-	extrd,u         pte,56,32,pte
+	extrd,u         pte,56,52,pte
 	idtlbt          pte,prot
 
 	rfir
@@ -1151,7 +1147,7 @@ nadtlb_check_flush_20w:
 	/* Get rid of prot bits and convert to page addr for idtlbt */
 
 	depdi		0,63,12,pte
-	extrd,u         pte,56,32,pte
+	extrd,u         pte,56,52,pte
 	idtlbt          pte,prot
 
 	rfir
@@ -1743,8 +1739,6 @@ dbit_nolock_20w:
 	space_to_prot   spc prot        /* create prot id from space */
 	depd            pte,8,7,prot    /* add in prot bits from pte */
 
-	extrd,u,*=      pte,_PAGE_NO_CACHE_BIT+32,1,r0
-	depdi		1,12,1,prot
 	extrd,u,*=      pte,_PAGE_USER_BIT+32,1,r0
 	depdi		7,11,3,prot   /* Set for user space (1 rsvd for read) */
 	extrd,u,*= 	pte,_PAGE_GATEWAY_BIT+32,1,r0
@@ -1753,7 +1747,7 @@ dbit_nolock_20w:
 	/* Get rid of prot bits and convert to page addr for idtlbt */
 
 	depdi		0,63,12,pte
-	extrd,u         pte,56,32,pte
+	extrd,u         pte,56,52,pte
 	idtlbt          pte,prot
 #ifdef CONFIG_SMP
 	CMPIB=,n        0,spc,dbit_nounlock_20w


-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Re: [parisc-linux] FB on c3k

[Grant Grundler]

Thomas Bogendoerfer wrote:
> right of me is a monitor connected to a B2600 with a X screen on it :-)

Cool!

> No jsm is right, the U bit doesn't matter, if we set the right
> physical address in the TLB. I really don't understand why it's
> needed to supply more than 40bit,

B2600 has PA-8600. Maybe PA-8600 needs 44 bits of physical address?
PA-8000 only needed 40-bits, iirc.
I thought N-class (PA-8500) used 44-bits.

> but with the patch below X works
> (fbi still crashes the machine, but that could be a font problem,
> as well). Before I'll commit the change, I'll post it here for
> comments.

I tried it with 32-bit kernel on c3k.  That hpmc'd.
(Vis-EG, 1600x1200 8bit).
Are you using 64-bit kernel?

It's bedtime here and I need to post a diff here as well.

thanks,
grant

Re: [parisc-linux] FB on c3k

[Thomas Bogendoerfer]

On Thu, Mar 07, 2002 at 12:31:16AM -0700, Grant Grundler wrote:
> Thomas Bogendoerfer wrote:
> > No jsm is right, the U bit doesn't matter, if we set the right
> > physical address in the TLB. I really don't understand why it's
> > needed to supply more than 40bit,
> 
> B2600 has PA-8600. Maybe PA-8600 needs 44 bits of physical address?
> PA-8000 only needed 40-bits, iirc.
> I thought N-class (PA-8500) used 44-bits.

after sleeping over the problem, I believe we were short just one bit. We
extracted 32 bits from the PTE. The lower 5 bits are zeroed and will
be the 4 size bits and the one 0 bit in the TLB. That leaves 27 bits for
the physical page number. Adding the 12 offset bits for 4k pages gives us
just 39 bits, but we need 40. So instead of the change 32 -> 52 a
change from 32 -> 33 should do the same. On the other side using all
bits shouldn't matter and we are prepared for 44 bit and more. BTW.
isn't our current PDC space expansion wrong for "odd" sized address
spaces ? It should work for 48 and 56, but not for anything else.
Or do I miss something ?

I'm packing for Cebit at the moment, and will be away for 2 weeks. So
I can't check my theory in the next days. I will have a J6700 at Cebit
to play with, but I don't think I'll get spare time in the next couple
of days.

> I tried it with 32-bit kernel on c3k.  That hpmc'd.
> (Vis-EG, 1600x1200 8bit).
> Are you using 64-bit kernel?

yes,  with your last ioctl32 changes. I need to recheck my first entry.S
hack for the narrow mode pa2.0 tlb handler. I think my assembler code
just sucks and setting up the tlbs the same way as for wide mode,
should get us X with 32-bit kernels, too.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Re: [parisc-linux] FB on c3k

[Grant Grundler]

Thomas Bogendoerfer wrote:
> after sleeping over the problem, I believe we were short just one bit.
> We extracted 32 bits from the PTE. The lower 5 bits are zeroed and will
> be the 4 size bits and the one 0 bit in the TLB. That leaves 27 bits for
> the physical page number. Adding the 12 offset bits for 4k pages gives us
> just 39 bits, but we need 40. So instead of the change 32 -> 52 a
> change from 32 -> 33 should do the same. On the other side using all
> bits shouldn't matter and we are prepared for 44 bit and more.

ok. that all make sense now.
It made more sense when I read about extru and idtlbt in the 
PA 2.0 Arch book.

> BTW.
> isn't our current PDC space expansion wrong for "odd" sized address
> spaces ? It should work for 48 and 56, but not for anything else.
> Or do I miss something ?

I have no clue. jsm or willy know?

> I will have a J6700 at Cebit to play with, but I don't think I'll
> get spare time in the next couple of days.

Done! See ftp://ftp.p-l.o/patches/entry.S-diff

The 32-bit kernel with FB is working with 4 instances of the following
change to entry.S (all immediately preceed an idtlbt instruction):
-       extrd,u         pte,56,25,pte
+       extrd,s         pte,56,25,pte   /* bit 31:8 >> 8  */
+       depdi           0,3,4,pte       /* page_size = 4k (in case signed) */

CAVEAT: This is better than the brokeness we had before.
But it doesn't properly handle 0xf0xxxxxx addresses.
Those need to be "f-extended" with 0xf0f0f0... instead of all 1's.

> yes,  with your last ioctl32 changes. I need to recheck my first entry.S
> hack for the narrow mode pa2.0 tlb handler. I think my assembler code
> just sucks and setting up the tlbs the same way as for wide mode,
> should get us X with 32-bit kernels, too.

Done. patch on ftp.p-l.o/patches/entry.S-diff.
Can someone with VM cluefulness review this for me?

It seems to be working on my c3k with Vis-EG/PCI now though...wohoo! :^)

thanks,
grant

Re: [parisc-linux] FB on c3k

[Carlos O'Donell Jr.]

On Thu, Mar 07, 2002 at 12:31:16AM -0700, Grant Grundler wrote:
> Thomas Bogendoerfer wrote:
> > right of me is a monitor connected to a B2600 with a X screen on it :-)
> 
> Cool!
>

Speaking of framebuffers. 

Anyone working with DirectFB? (http://www.directfb.org)

I just recently compiled DirectFB on our 715/50 cluster, so I can get
a lightweight library ontop of fbdev (thanks for moral support Fleedwood!)

The only supported mode is RGB332 which is like a fixed index 8-bit vis.
It's displaying stuff (I think, with wrong colours). I'm just at a loss 
to find the right colour palette for 3,3,2 ? :)

More research needed!

c. 

Re: [parisc-linux] FB on c3k

[Grant Grundler]

"M. Grabert" wrote:
> very nice!
> Is the Visual-EG of the same type as the Visual-EG in my C240?

Same generation, but I'm using "Vis-EG/PCI" vs plain "Vis-EG".
I expect them to be the same (prgramming model) but don't know
if they actually are.

> Can you use the driver for Visual-FX aswell (AFAIK these are similar) ?

They are not similar. Vis-EG is 1280x1024 8 bit.
Vis-FX are all 24-bit color. FX2/4/6 have 3d acceleration
and texture mapping functionality (AFAIK, Vis-FXe does not)
I think Vis-FX can handle higher resolutions as well.

> Packed pixel:
> 
> If you see stripes it is very likely that you mix up PACKED pixels and
> NONPACKED pixels. But I think that's what you already checked.

I haven't. "PACKED PIXEL" is what the kernel currently hands back.
I believe this works for Vis-EG/GSC on PA1.1 machines.

> Mini-tiles/Packed pixel:
...
> Interleaved:
...
I don't think Vis-EG/PCI uses either of the above.

> BTW, Is the color of the displayed picture alright ?

I can't tell since the visible portions are only black.
Maybe that's a hint they are not.

> Is the picture streched/compressed or cropped ?
> You didn't say whether the Tux picture also had black stripes.

Both STICON text and Tux are striped diagonally top-left
to bottom right.

> Try to use some test-pictures (e.g. all red, all green. all blue,
> check-boxed, special patterns ...)!

That's a good idea. I setup some GIF for that.

> Actually I don't think I'm telling you any new stuff.
> So let's stop here and I wish you good luck!

For me, much of it is new. I don't know anything about FB layout.

thanks,
grant

Re: [parisc-linux] FB on c3k

[M. Grabert]

On Wed, 6 Mar 2002, Grant Grundler wrote:

> "M. Grabert" wrote:
> > very nice!
> > Is the Visual-EG of the same type as the Visual-EG in my C240?

Arghhll. Forget it, I have a Visualize-FX2 (A4552A) card!
I should really now my system ;)

> > Can you use the driver for Visual-FX aswell (AFAIK these are similar) ?

except for the fact that FX do 3D and EG not ;)

> They are not similar. Vis-EG is 1280x1024 8 bit.
> Vis-FX are all 24-bit color. FX2/4/6 have 3d acceleration
> and texture mapping functionality (AFAIK, Vis-FXe does not)
> I think Vis-FX can handle higher resolutions as well.

Well, I was talking about the 2D stuff. I suppose the
2D drawing commands are the same as on the -EG (at least I hope so).

Does anybody know a good PCI graphics card (Universal or 3.3 voltage)
that is supported in XFree-4 (and may run in a C240) ?

Thanks max

2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded

[Thomas Bogendoerfer]

After syncing my two source trees with CVS, I've exported a tarball
and uploaded it to

ftp://ftp.linux.sgi.com/pub/linux/mips/test/linux-2.2.1-990226.tar.gz

I've tested compilation for Indy and Olivetti M700 (MIPS Magnum).

I also uploaded a Indy kernel (map and .config file included):

ftp://ftp.linux.sgi.com/pub/linux/mips/test/vmlinux-indy-2.2.1-990226.tar.gz

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: 2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded

[gkm]

> After syncing my two source trees with CVS, I've exported a tarball
> and uploaded it to
> 
> ftp://ftp.linux.sgi.com/pub/linux/mips/test/linux-2.2.1-990226.tar.gz
> 
I've tried compiling this on a base hardhat installation and here's the 
resuults so far.. (no, haven't gotten a kernel out of it yet)

First, there's no modutils.  I grabbed modutils2.1.121 and that compiled and 
installed fine.
Next, it almost immediately blew up on a lack of a current structure.
I found that /usr/include/asm/current.h had a conditional defining of the 
struct if C_language was defines, and something else if ASMing.  I just took 
out the conditional(don't know if it's the right thing, but compiling went 
alot further)
Lastly(and most messily) it got to arch mips and tried some ASMing.
Here's a short piece of that:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -pipe -c indyIRQ.S -o indyIRQ.o
/usr/src/linux/include/asm/mipsregs.h: Assembler messages:
/usr/src/linux/include/asm/mipsregs.h:177: Error: unrecognized opcode `extern'
/usr/src/linux/include/asm/mipsregs.h:177: Error: Bad expression
/usr/src/linux/include/asm/mipsregs.h:177: Error: Missing ')' assumed
/usr/src/linux/include/asm/mipsregs.h:177: Error: Rest of line ignored. First ignored character is `i'.
/usr/src/linux/include/asm/mipsregs.h:177: Error: unrecognized opcode `__asm__'
/usr/src/linux/include/asm/mipsregs.h:177: Error: unrecognized opcode `__res'
/usr/src/linux/include/asm/mipsregs.h:177: Error: Rest of line ignored. First ignored character is `}'.
/usr/src/linux/include/asm/mipsregs.h:177: Error: unrecognized opcode `res'
/usr/src/linux/include/asm/mipsregs.h:177: Error: unrecognized opcode `res'

How has everyone else faired in the compiling game?  :)

Greg

Re: 2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded

[Thomas Bogendoerfer]

On Fri, Feb 26, 1999 at 11:30:50PM -0500, gkm@total.net wrote:
> How has everyone else faired in the compiling game?  :)

it worked out of the box, but not on an out of the box HardHat:-(

HardHat has still gcc-2.7.2 as the default C compiler and this
compiler has different defines. So either use egcs or update your
gcc specs file (sorry, I couldn't find the patch right now, anyone ?)

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: 2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded

[Michael Hill]

On Feb 27, 12:01pm, Thomas Bogendoerfer wrote:
> Subject: Re: 2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded
> On Fri, Feb 26, 1999 at 11:30:50PM -0500, gkm@total.net wrote:
> > How has everyone else faired in the compiling game?  :)
>
> it worked out of the box, but not on an out of the box HardHat:-(
>

Works here out of the box using hardhat egcs.

Still have the aforementioned video quirks.  Any further developments regarding
Newport revisions?

Mike

Re: 2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded

[Thomas Bogendoerfer]

On Sun, Feb 28, 1999 at 05:16:59PM -0500, Michael Hill wrote:
> Still have the aforementioned video quirks.  Any further developments 
> regarding Newport revisions?

so far nobody could tell me, how I can read the newport revision. Without
this information it's impossible to implement a runtime workaround for
the cursor problem (and mabye others).

So once again:

Is there anybody on this list, who knows and is willing to tell me, how I
get the newport revision ?

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: 2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded

[Ulf Carlsson]

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

On Sat, Feb 27, 1999 at 12:01:44PM +0100, Thomas Bogendoerfer wrote:
> On Fri, Feb 26, 1999 at 11:30:50PM -0500, gkm@total.net wrote:
> > How has everyone else faired in the compiling game?  :)
> 
> it worked out of the box, but not on an out of the box HardHat:-(
> 
> HardHat has still gcc-2.7.2 as the default C compiler and this
> compiler has different defines. So either use egcs or update your
> gcc specs file (sorry, I couldn't find the patch right now, anyone ?)

Ooops, sorry about the delay but here's the specs man and here's his specs file!

The specs man says: Take this specs file and put it in
/usr/local/lib/gcc-lib/mips-linux/2.7.2.2 or similar..

- Ulf

[-- Attachment #2: specs --]
[-- Type: text/plain, Size: 4048 bytes --]

*asm:
%{mcpu=*} %{m4650} %{mmad:-m4650} %{G*} %{EB} %{EL} %{mips1} %{mips2} %{mips3} %{mips4} %{v} %{noasmopt:-O0} %{!noasmopt:%{O:-O2} %{O1:-O2} %{O2:-O2} %{O3:-O3}} %{g} %{g0} %{g1} %{g2} %{g3} %{ggdb:-g} %{ggdb0:-g0} %{ggdb1:-g1} %{ggdb2:-g2} %{ggdb3:-g3} %{gstabs:-g} %{gstabs0:-g0} %{gstabs1:-g1} %{gstabs2:-g2} %{gstabs3:-g3} %{gstabs+:-g} %{gstabs+0:-g0} %{gstabs+1:-g1} %{gstabs+2:-g2} %{gstabs+3:-g3} %{gcoff:-g} %{gcoff0:-g0} %{gcoff1:-g1} %{gcoff2:-g2} %{gcoff3:-g3} %{!fno-PIC:%{!fno-pic:-KPIC}} %{fPIC:-KPIC} %{fpic:-KPIC} %{fno-PIC:-non_shared} %{fno-pic:-non_shared} %{membedded-pic}

*asm_final:


*cpp:
%{.cc:	-D__LANGUAGE_C_PLUS_PLUS__ -D__LANGUAGE_C_PLUS_PLUS -D_LANGUAGE_C_PLUS_PLUS  %{!ansi:-DLANGUAGE_C_PLUS_PLUS}} %{.cxx:	-D__LANGUAGE_C_PLUS_PLUS__ -D__LANGUAGE_C_PLUS_PLUS -D_LANGUAGE_C_PLUS_PLUS %{!ansi:-DLANGUAGE_C_PLUS_PLUS}} %{.C:	-D__LANGUAGE_C_PLUS_PLUS__ -D__LANGUAGE_C_PLUS_PLUS -D_LANGUAGE_C_PLUS_PLUS %{!ansi:-DLANGUAGE_C_PLUS_PLUS}} %{.m:	-D__LANGUAGE_OBJECTIVE_C__ -D__LANGUAGE_OBJECTIVE_C -D_LANGUAGE_OBJECTIVE_C %{!ansi:-DLANGUAGE_OBJECTIVE_C}} %{.S:	-D__LANGUAGE_ASSEMBLY__ -D__LANGUAGE_ASSEMBLY -D_LANGUAGE_ASSEMBLY %{!ansi:-DLANGUAGE_ASSEMBLY }} %{.s:	-D__LANGUAGE_ASSEMBLY__ -D__LANGUAGE_ASSEMBLY -D_LANGUAGE_ASSEMBLY %{!ansi:-DLANGUAGE_ASSEMBLY }} %{!.S:%{!.s:-D__LANGUAGE_C__ -D__LANGUAGE_C -D_LANGUAGE_C %{!ansi:-DLANGUAGE_C }}} %{mfp32: -D_MIPS_FPSET=16}%{!mfp32: -D_MIPS_FPSET=32} %{mips1: -D_MIPS_ISA=_MIPS_ISA_MIPS1} %{mips2: -D_MIPS_ISA=_MIPS_ISA_MIPS2} %{mips3: -D_MIPS_ISA=_MIPS_ISA_MIPS3} %{mips4: -D_MIPS_ISA=_MIPS_ISA_MIPS4} %{!mips1: %{!mips2: %{!mips3: !
%{!mips4: -D_MIPS_ISA=_MIPS_ISA_MIPS1}}}} %{mint64:-D_MIPS_SZINT=64 %{!mlong64:-D__SIZE_TYPE__=long\ unsigned\ int -D__SSIZE_TYPE__=long\ int -D__PTRDIFF_TYPE__=long\ int -D_MIPS_SZLONG=64 -D_MIPS_SZPTR=64}} %{!mint64:-D_MIPS_SZINT=32 %{!mlong64:-D__SIZE_TYPE__=unsigned\ int -D__SSIZE_TYPE__=int -D__PTRDIFF_TYPE__=int -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32}} %{mlong64:-D__SIZE_TYPE__=long\ unsigned\ int -D__SSIZE_TYPE__=long\ int -D__PTRDIFF_TYPE__=long\ int -D_MIPS_SZLONG=64 -D_MIPS_SZPTR=64} %{mips3:-U__mips -D__mips=3 -D__mips64} %{mips4:-U__mips -D__mips=4 -D__mips64} %{mgp32:-U__mips64} %{mgp64:-D__mips64} %{EB:-UMIPSEL -U__MIPSEL__ -D__MIPSEB__ %{!ansi:-DMIPSEB}} %{EL:-UMIPSEB -U__MIPSEB__ -D__MIPSEL__ %{!ansi:-DMIPSEL}} %{fno-PIC:-U__PIC__ -U__pic__} %{fno-pic:-U__PIC__ -U__pic__} %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{-D__HAVE_FPU__ } %{posix:-D_POSIX_SOURCE}

*cc1:
%{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1}}}}} %{mips1:-mfp32 -mgp32}%{mips2:-mfp32 -mgp32}%{mips3:%{!msingle-float:%{!m4650:-mfp64}} -mgp64} %{mips4:%{!msingle-float:%{!m4650:-mfp64}} -mgp64} %{mfp64:%{msingle-float:%emay not use both -mfp64 and -msingle-float}} %{mfp64:%{m4650:%emay not use both -mfp64 and -m4650}} %{m4650:-mcpu=r4650} %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} %{pic-none:   -mno-half-pic} %{pic-lib:    -mhalf-pic} %{pic-extern: -mhalf-pic} %{pic-calls:  -mhalf-pic} %{save-temps: }

*cc1plus:


*endfile:
%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s

*link:
%{G*} %{EB} %{EL} %{mips1} %{mips2} %{mips3} %{mips4} %{bestGnum} %{shared} %{non_shared} %{call_shared} %{no_archive} %{exact_version}   %{!shared:       %{!static: 	%{rdynamic:-export-dynamic} 	%{!dynamic-linker:-dynamic-linker /lib/ld.so.1}} 	%{static:-static}}

*lib:
%{!shared: %{mieee-fp:-lieee} %{p:-lgmon} %{pg:-lgmon}      %{!ggdb:-lc} %{ggdb:-lg}}

*libgcc:
%{!shared:-lgcc}

*startfile:
%{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s}                        %{!p:%{profile:gcrt1.o%s}                          %{!profile:crt1.o%s}}}}    crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}

*switches_need_spaces:


*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}

*predefines:
-D__ELF__ -D_MIPS_SIM=_MIPS_SIM_ABI32 -D__PIC__ -D__pic__ -Dunix -Dmips -DR3000 -DMIPSEB -Dlinux -Asystem(linux) -Asystem(posix) -Acpu(mips) -Amachine(mips)

*cross_compile:
1

*multilib:
. !EL !EB;el EL !EB;eb !EL EB;

Re: 2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded

[Chad Carlin]

Thomas,

Anyone else have trouble with these on an R4400? I tried a couple times. Both
stopped the boot process a the "freeing unused memory" part. Sorry there was no
other info.

Regards,
Chad


Thomas Bogendoerfer wrote:

> After syncing my two source trees with CVS, I've exported a tarball
> and uploaded it to
>
> ftp://ftp.linux.sgi.com/pub/linux/mips/test/linux-2.2.1-990226.tar.gz
>
> I've tested compilation for Indy and Olivetti M700 (MIPS Magnum).
>
> I also uploaded a Indy kernel (map and .config file included):
>
> ftp://ftp.linux.sgi.com/pub/linux/mips/test/vmlinux-indy-2.2.1-990226.tar.gz
>
> Thomas.
>
> --
>    This device has completely bogus header. Compaq scores again :-|
> It's a host bridge, but it should be called ghost bridge instead ;^)
>                                         [Martin `MJ' Mares on linux-kernel]

--
           -----------------------------------------------------
            Chad Carlin                          Special Systems
            Silicon Graphics Inc.                   972.205.5911
            Pager 888.754.1597          VMail 800.414.7994 X5344
            chad@sgi.com             http://reality.sgi.com/chad
           -----------------------------------------------------
        "flying through hyper space ain't like dusting crops, boy"

Re: 2.2.1 MIPS kernel sources plus Indy kernel binaries uploaded

[ralf]

On Fri, Mar 05, 1999 at 06:35:41PM -0600, Chad Carlin wrote:

> Anyone else have trouble with these on an R4400? I tried a couple times. Both
> stopped the boot process a the "freeing unused memory" part. Sorry there was no

It seems one of the ``high priests'' will need get access to one of these
machine in order to debug the problem.

Did you try the usual hot keys to get a register dump?  If that still works,
what is the epc value, is the machine looping?

  Ralf