RE: Framebuffer with banked memory

  The short answer to your problem is that, sadly, much of the 2.4
framebuffer is badly implemented, allowing device independent code to
directly access device memory etc. Some of this is cleaned up for 2.5, but
as I've not looked at it lately I'm not sure how much.  Here are some
pointers as to what is required for 2.4.

#1 The Boot penguin code directly accesses your video memory. If you have
banked memory this will likely fall off the end of a pointer and oops the
kernel or worse.

Fixed in 2.5.X. You use the image drawing function to draw the penguin.

#2 Read/Write Access video memory directly. I had added a read/write
handler to the fb_ops to hook these out and switch banks.
Read/write are also incorrect if your pitch != width.

Fixed. I have hooks now. I didn't notice the pitch != width problem. Give
me time to fix up a patch, unless someone bets me to the punch.

#3 Memory map can't be done. I had coded up a working version that would
map a single back and page fault in the banks as necessary. This worked
but would get hung up on unaligned accesses where one instruction accessed
two memory banks at the same time. So memory map isn't possible.

:-( Even with providing your own mmap function you still couldn't get it
to work.




-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en