[Open-graphics] From PCI to VGA registers

[Michael Meeuwisse]

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