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
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
