On Sat, Jul 26, 2008 at 8:25 PM, Mark Marshall <[EMAIL PROTECTED]> wrote: > Hi. > > I've been reading through the PCI spec and the RTL for the OGD1 for most of > the day, but there are still some major things that I don't quite > understand. It would be great if someone could help me out here. > > I'm trying to understand where the different aprts of the hardware will > appear in the PC address space. We have these things that I expect to be > able to see; An option ROM, VGA IO Registers, VGA Memory, OGD Registers and > OGD Memory.
I presume you've found pci/config_space.v, starting at line 179. > > For OGD1 we are implementing a "VGA Compatable Controller" (that's what > we're telling the PCI Configuration space). This gives us a Class of 0x03, > 0x00, 0x00. Actually, I think we have one of those wrong, because the host isn't recognizing it as a graphics device. It's a bit odd. I haven't investigated it yet. > In Appendix G of the PCI LB 3.0 spec (pci_lb3.0-2-6-04.pdf) it says that a > "Legacy Device" can claim those IO ports without having to setup a BAR. > This seems to be how things work in our RTL, VGA IO addresses 0x3B0-0x3DF > are decoded. > > At first I thought that this appendix meant that the VGA memory region > between 0xA0000 - 0xBFFFF should also be decoded without adding a BAR, but > I'm now not sure. What we'll do is temporarily reposition what BAR0 decodes. One thing that's missing is dynamic sizing of apertures, which will be a simple fix. > The ROM address is set by the Expansion ROM field of the Config space, so > that doesn't need an explicit BAR either. The BIOS will copy this from into > memory at 0xC0000 during the boot process (I'm assuming PCI 2.1 behavior). > > So this leaves us with two BAR's in the RTL. The "small" one is 256 KBytes > in size and is the OGD Registers. The fact that it's 16 times too big > doesn't matter. Actually, it's only 4 times too big. The S3 segments the register space into 64 1024-word (4K byte) sections. That's 256K bytes. > The second BAR is "raw" access to our memory. This is 256 MBytes as I'd > expect. > > So I'm not sure who (if anyone) is decoding the memory range 0xA0000 - > 0xBFFFF? I would have thought that we would be doing that, but I can't see > anything to indicate that we are. Previous posts have stated that the HQ > will get to see these, but I don't see how at the moment. What can do is have a register in the engine space or a register in the extended config space that'll default (reset) to a mask that corresponds to 256 MB for decoding. The driver and/or BIOS will save the address programmed by the system BIOS and the size (that it resets to) and replace them with the numbers appropriate to decoding the region you refer to. We can provide some scratch registers in the hardware as a place to store these. When regular graphics takes over, we can reload the original location and size. Another option (maybe a better one) is to reenable the logic for decoding BAR2, but have it default to a configuration that doesn't respond to anything (so the BIOS won't allocate any address space to it). For VGA, we can program the size and address to point where we want, and when we're done with it, we just turn it off. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
