Messages in this thread | | | From | "Tom Leete" <> | Subject | Re: holes for ISA boards... | Date | Sat, 12 Jun 1999 02:17:54 -0400 |
| |
Hirling Endre <endre@darmol.elte.hu> wrote:
>On Fri, 11 Jun 1999, Aaron J. Grier wrote: > >> Any idea what's going on? Is it impossible for me to poke a hole in memory >> from 12-16MB so I can hack on this silly ISA board? > >Your patch creates a hole in Linux's virtual address space, but your >card needs a hole in the physical RAM, or it will conflict with chips >in that range. I think there's no way to do this with a machine that >has more than 12M of RAM.
IIRC, ISA busmastering devices are able to treat the conflicting memory as a physical framebuffer, allowing protected mode writes to be mirrored in device memory. The X server or device driver has to know how to set this up.
Here's My Rant (tm). Not directed at HE or AJG.
The question of support for ISA accelerated SVGA cards is a FAQ, or ought to be. IMHO it is shameful that the answer is "You can't do that."
The form of that answer is usually "Buy a new video card." I grit my teeth at that and think "Don't change the subject." Problem hardware is not the same thing as a hardware problem.
There are millions of those things out there. They are exactly the cards that the best kind of novice Linux users are likely to have. Why do I think that? They are the thrifty users who won't let old hardware gather dust. They are the cautious ones who want to learn Linux on an old beater before entrusting the shiny new machine to it. These are people who will look for efficiencies and file good bug reports. They will be a counterweight to those who are here for the beer and want lots of bloaty decorations.
It seems like kernel guys have been relying on the X guys to do it, and the X guys have been waiting for memory hole support from the kernel. Deadlock. At least that's how it looks to me.
I see three possible solutions to the problem, aside from (pre-1). "Buy a new video card", which is OT. Other suggestions are solicited.
(1) Modify vm initialization to create the hole, and map it as a physical framebuffer. This is Aaron's approach, as I understand it. Properly modified, I think it's the most general and direct way. It is a colossal frag of vm, but that may be unavoidable with this kind of device. Since it's large, contiguous. and (I hope) static, the vm hit may not be too severe.
(2) Use bigphysarea to grab everything below 16M. Buy more memory to compensate for the loss. This map could support a not-yet-invented isafb device with one physical framebuffer and several virtual ones to swap. Use the leftovers for sound DMA buffers and the like. This is wasteful and not really what I want, though it might make a great game machine. X might really cook too.
(3) I dimly recall that the PCI bridge device was supposed to be able to remap the ISA bus. If true, this might be the real solution for most of us. Does the kernel PCI code support such a thing? I'm looking, but I haven't found any answers yet. PCI gurus? This might sidestep the deadlock and let existing drivers do the job.
Let me anticipate flamage by saying that I already know Wintel is abolishing the ISA bus. That won't replace the ones I have but slowly. I sure do hate to waste old gear.
Whew, Now I Feel Better, Tom
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |