[Linux-ia64] framebuffer console

[Linux-ia64] framebuffer console

[Richard Hirst]

Hi,
  I've been trying to use the framebuffer console to display simple
graphics with only partial success.  I'm using an nVidia Quadro2 card,
and a 2.4.9 kernel.

Would be nice to use CONFIG_FB_VESA so I was graphics card independent,
but there is some x86 assembler in that source, and I believe it relies
on video mode switching being done before the kernel starts as well.

So, I've compiled with CONFIG_FB_RIVA, and am experimenting with fbi, a
simple image viewer for the framebuffer console.  This mmaps the framebuffer
memory, and tries to memcpy() in to it.  That reliably causes hard
crashes and spontaneous system reboots.  If I hack fbi to do lseek/write
on /dev/fb0 rather than mmap(), it seems to work ok.

When using mmap() I sometimes see parts of my image on the screen before
it crashes, and the pattern of bits that are drawn (or not) indicate
that some small blocks of data (cachelines?) are not written to the
video memory while other similar sized blocks are written.  As the system
crashes so badly, I guess the missing blocks are written elsewhere.

The other thing that struck me as odd (but unrelated) was that on boot I
get two penguins at the top of the screen, where I'd expected only one..

So, has anyone else played with framebuffer console, and been more
successful than me?  Is the problem I'm seeing likely to be specific
to my graphics card, or something more generic?

Thanks,
  Richard

Re: [Linux-ia64] framebuffer console

[Richard Hirst]

On Wed, Oct 24, 2001 at 11:30:33AM +0100, Richard Hirst wrote:
> When using mmap() I sometimes see parts of my image on the screen before
> it crashes, and the pattern of bits that are drawn (or not) indicate
> that some small blocks of data (cachelines?) are not written to the
> video memory while other similar sized blocks are written.  As the system
> crashes so badly, I guess the missing blocks are written elsewhere.

This patch solves the problem.  Still surprised that cached accesses to
the video memory crash the machine though..

Richard


--- drivers/video/fbmem.c-	Wed Oct 24 15:17:36 2001
+++ drivers/video/fbmem.c	Wed Oct 24 14:50:50 2001
@@ -605,6 +605,8 @@
 	vma->vm_flags |= VM_IO;
 #elif defined(__sh__)
 	pgprot_val(vma->vm_page_prot) &= ~_PAGE_CACHABLE;
+#elif defined(__ia64__)
+	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 #else
 #warning What do we have to do here??
 #endif

Re: [Linux-ia64] framebuffer console

[Roman Hodek]

> This patch solves the problem. Still surprised that cached accesses
> to the video memory crash the machine though..

I've seen similar, really hard crashes already, too. IMHO it seems
that the AGP bridge in the chipset doesn't like wide accesses
generated when filling or writing out cache lines.

Roman

Re: [Linux-ia64] framebuffer console

[Roman Hodek]

> Would be nice to use CONFIG_FB_VESA so I was graphics card
> independent, but there is some x86 assembler in that source, and I
> believe it relies on video mode switching being done before the
> kernel starts as well.

Yep, vesafb is an i386-specific hack... :(
I already thought about a generic replacement, but EFI doesn't have
any resolution-related calls (AFAICS).

> So, has anyone else played with framebuffer console, and been more
> successful than me? Is the problem I'm seeing likely to be specific
> to my graphics card, or something more generic?

I've once played with it (some months ago), and aty128fb worked ok so
far. But I've only tested text on the console, no real graphics.
Anyway, your problems more sounds like portability problems in rivafb...

Roman

Re: [Linux-ia64] framebuffer console

[David Mosberger]

>>>>> On Wed, 24 Oct 2001 12:26:59 +0100, Richard Hirst <rhirst@linuxcare.com> said:

  Richard> This patch solves the problem.  Still surprised that cached
  Richard> accesses to the video memory crash the machine though..

My understanding is that Merced doesn't handle cache line sized
transactions to the PCI bus.  Instead of going uncached, you might be
able to use write-combining (for the video framebuffer, not for memory
mapped control registers).  That can give you noticably better
performance.

	--david

Re: [Linux-ia64] framebuffer console

[Richard Hirst]

On Wed, Oct 24, 2001 at 04:21:08PM -0700, David Mosberger wrote:
> >>>>> On Wed, 24 Oct 2001 12:26:59 +0100, Richard Hirst <rhirst@linuxcare.com> said:
> 
>   Richard> This patch solves the problem.  Still surprised that cached
>   Richard> accesses to the video memory crash the machine though..
> 
> My understanding is that Merced doesn't handle cache line sized
> transactions to the PCI bus.  Instead of going uncached, you might be
> able to use write-combining (for the video framebuffer, not for memory
> mapped control registers).  That can give you noticably better
> performance.

Yes, write combining works.  Could you include this in your tree
please, (patch is from a 2.4.9 tree)

Thanks,
  Richard



--- linux/drivers/video/fbmem.c.ori	Mon Nov  5 01:53:01 2001
+++ linux/drivers/video/fbmem.c	Mon Nov  5 01:53:05 2001
@@ -605,6 +605,8 @@
 	vma->vm_flags |= VM_IO;
 #elif defined(__sh__)
 	pgprot_val(vma->vm_page_prot) &= ~_PAGE_CACHABLE;
+#elif defined(__ia64__)
+	vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
 #else
 #warning What do we have to do here??
 #endif

Re: [Linux-ia64] framebuffer console

[David Mosberger]

>>>>> On Sun, 4 Nov 2001 22:06:37 +0000, Richard Hirst <rhirst@linuxcare.com> said:

  Richard> Yes, write combining works.  Could you include this in your
  Richard> tree please, (patch is from a 2.4.9 tree)

Great!  I applied the patch.

Thanks,

	--david