On 9 Aug 2007, at 22:52, Timothy Normand Miller wrote:
We're some way off from having VGA working. Here are a few of the
things that need to be finished to support it:
- _Our_ PCI controller has never actually been tested in hardware.
We've actually been using someone else's (with permission, of course).
We need to test ours in hardware so that we can decode those I/O
space accesses.
- We need to finish the nanocontroller and integrate it.
- We need to write a VGA BIOS to configure it on boot.
Why the nanocontroller exactly? Anything specific or just general
'ordering of things'? I'm guessing that's going to need some sort of
microcode as well, which needs to be written.
All addresses are broadcast to all devices. It is the device's
responsibility to "claim" a particular transaction based on it
matching a configured address range.
Ah, get it.
Well, our decode of I/O space will be disabled by default, so in our
VGA BIOS, we'll have to flip a bit (we'll probably put it in extended
config space) to turn it on. Other than that, nothing special.
Yeah ok, but we don't have to drive a specific pin low on a specific
moment to let the main BIOS know we want to do stuff.
Nothing magic. The system BIOS probes each device's EPROM and looks
for a particular header format. Part of that header is an x86 jump
instruction. For a VGA console, the system BIOS jumps through that,
and so our code executes.
So, in our code, we're supposed to modify the interrupt table to point
to some of our own code or something like that. We may also have to
store the original vector so that we can forward requests we don't
want.
I found the appropriate second in the PCI Specification, I'll read up
on it.
Yeah. PCI devices have a special BAR that points to the EPROM. The
system BIOS will enable that and either shadow it in RAM or execute
directly from that address space.
What exactly do you mean with BAR? Is that short for "Base Address
Register" in
the configuration space? If so, I get it (I think, the 'base' part is
a little vague)
Also, how is the a000h memory range mapped to our
device?
We decide how it gets mapped. I'm not sure exactly how to make just a
small piece of an aperture, though.
We're pretty much stuck to this location because as you said earlier
(and I've done a few
times myself) some applications write directly to that location. I
meant more as in, for interrupts
there's an interrupt table, is there a table for memory mappings as
well in real mode?
In safe mode I assume we just have to use a driver which talks to the
PCI bios somehow to do memory read/writes, which on the PCI card are
picked up as commands w/ data. Correct?
If you're talking about like Windows "safe mode", basically,
everything just thunks to real mode and uses int calls to the BIOS.
This, I believe, is how the VESA driver works in Linux.
Sorry, I meant protected mode. And switching back to real mode is
expensive, I really
hope that isn't happening in the VESA driver. But who knows.
Yes and no. PCI provides a way to chain multiple firmwares in ROM.
One header points to the next header, etc. So we can include firmware
for PC, SPARC, Alpha, HP, etc. The PC only maps 64k bytes, so we'd
put the PC code first. Other platforms can map the whole thing, so we
can stack them further down.
Again, I'll read up on it. Thanks again for the suggestion,
everything is starting to make a whole
lot more sense right now :)
Mike
www.wacco.mveas.com
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
