[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