On 8/9/07, Michael Meeuwisse <[EMAIL PROTECTED]> wrote: > > 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'?
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'm guessing that's going to need some sort of > microcode as well, which needs to be written. Yes, I did neglect to mention that. :) > > 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. Correct. > > 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. :) > > > >> 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? 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. > >> 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. I think it might be, although I've noticed that there are chunks of code in certain VGA BIOSs that are 32-bit code. I don't know how it works. > > 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 :) No problem. Excellent set of questions! -- 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)
