The linux 3c523 driver in 2.1.92 hasn't been updated to deal with
the required physical to virtual mapping. The following patch
is enough to make it boot on my machine:
--- 3c523.c.orig Sat Apr 4 14:46:55 1998
+++ 3c523.c Sat Apr 4 11:29:49 1998
@@ -529,7 +529,7 @@
Which we don't care much about here. We'll just tell Linux that
we're using 16K. MCA won't permit adress space conflicts caused
by not mapping the other 8K. */
- dev->mem_start = shm_table[ (status & ELMC_STATUS_MEMORY_SELECT) >> 3];
+ dev->mem_start = phys_to_virt(shm_table[ (status & ELMC_STATUS_MEMORY_SELECT) >> 3]);
/* We're using MCA, so it's a given that the information about memory
size is correct. The Crynwr drivers do something like this. */
However, I'm told that this kind of patch is unacceptable for the
distribution kernel, because the mapping is not guaranteed to be
linear.
Unfortunately, I don't understand that comment: the physical memory is
guaranteed to be 16k of contiguous memory, is it possible that the
kernel somehow mutilates the address space such that the virtual
addresses become dispersed? Or, is it possible that the kernel will
re-map the addresses as time goes on?
The reason I ask is: the driver currently uses operations like memset
and memcpy on the card's memory, and it seems just plain silly to cast
these operations as a sequence writeb (or something more complex).
Can someone who is familiar with this aspect of the kernel clue me in?
Thanks,
-- Raul
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu