Hello,

> > It is possible, provided you're using 3.0 or newer. Older versions
> > don't have wscons. On 2.x you can still use /dev/fb* but mmap()ing
> > PCI framebuffers will be tricky.
> 
> Thanks for your reply. I'm running -current, so I'm really interested
> only in wscons stuff. Machine is Ultra 5 (mach64 graphics).
> 
> For some unknown reason following code fails on sparc64 (but works on
> macppc):
> 
> 	fb_memory = (u_char*) mmap(0, fb_size, PROT_READ | PROT_WRITE,
> MAP_SHARED, fb_fd, 0);
> 
> 	mmap returns MAP_FAILED and errno is set to EINVAL. I double
> checked everything, and I'm sure that fb_size and fb_fd parameters are
> fine.
> 
> Any ideas?

Yes.
There's a problem with this - we allow to mmap() all PCI resources
through wscons so X can use them. The problem with mach64 is that some
Sun firmware likes to put a memory mapped register block to 0x2000 or
something in this range which collides with the framebuffer mapping at
0, so to make X work I had to remove the framebuffer mapping. This
problem is pretty much specific to 64bit architectures since on 32bit
machines the PCI bus doesn't really use the full 4GB address range to
avoid collisions with real memory. On sparc64 it has a full 4GB range
which doesn't collide with anything and sometimes the firmware uses it.
So, you can still map the framebuffer - just use the main aperture in
BAR 0x10. The PCI ioctl()s work on the wscons file descriptor. Read the
BAR, use it as mmap offset. 
I'm not quite sure yet how to resolve this, turning off the framebuffer
mapping at 0 is clearly not the right thing to do. On the other hand I
don't want to mess with the BARs if I can avoid it, I'd prefer to use
whatever the firmware sets up. If we start messing with one BAR we need
to keep track of all of them to avoid collisions which is quite a lot of
work since a lot of the sparc64-specific PCI bus support would need to
be rewritten.

have fun
Michael