[Open-graphics] From PCI to VGA registers

[Michael Meeuwisse]

On 10 Aug 2007, at 02:57, Timothy Normand Miller wrote:

> One discussion was about managing DMA transactions (controlling the
> PCI master and also decoding command packets).  Another discussion was
> about VGA.  In either case, it might be more cost-effective to develop
> dedicated control logic.  But given that both DMA and VGA won't be
> used at the same time, along with the advantages of having something
> more flexibly programmable, we decided to go ahead and develop a
> simple contoller to manage them.  (For VGA, the controller's job is to
> emulate VGA by translating from text characters to pixels in the
> background, rather than putting the translation logic into the video
> section.)
I've glanced over the OGA1HQ implementation and found the discussion  
(including an odd assembler) from march/april, but I'll get into  
these details later. Don't want to do everything at the same time. :)

>>> 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)
>
> Yes, Base Address Register.  BTW, sometimes, we'll refer to the memory
> space itself (configured by the register) also as a "BAR."  My wife,
> with her two graduate degrees, tells me that this is a form of
> metonymy.  :)

Metonywhat? :)
I don't completely get it yet. The main BIOS will write 0xFFFFFFFF to  
it on boot, we set it to how much memory we want, and then the BIOS  
will set a particular address in it which is then where we're  
'mapped'? That's how I understood section 6.2.5.1 of spec 2.2, which  
sounds like these registers have a dual purpose. Am I right?

Also I noticed there are 20 of them, plus another one purely for the  
Expansion ROM. Makes more sense, I initially thought there was only  
one. :)

> Besides the config space of the device itself, there's probably some
> mapping hardware in the CPU or host chipset we can muck about with.
>
> We may want to make it configuration just how much of a aperture we'll
> decode.  This way if, say, BAR1 can map 256 megabytes, but for the
> moment, we want 32K bytes, we can just change the BAR to point to A000
> and also limit the decode to 32K.  I feel like I'm missing something
> important here, though, because I know that when I did something like
> this with the i128, it was trivial.

As I understood it we (the PCI card) can't, the BIOS and/or system  
can. Although it's a bit unclear if this is tracked only in the BARs  
of all devices, or shadowed somewhere else.

>>> 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.

Done. I had to LOL when I saw that the 'magic header' is 0x55AA. How  
original!
Anyway, I'm going to have a look at how much work it'll be to write  
this setup code for the PC platform. Hopefully next week I'll find  
some time to cook up assembly. It doesn't seem to hard now that the  
overall picture is getting clearer.

Famous last words ;)

Mike
www.wacco.mveas.com