On 8/9/07, Michael Meeuwisse <[EMAIL PROTECTED]> wrote: > > So the X driver does everything through memory space, and only the > VGA bit is optionally > done through I/O? And that's currently not working yet? Aka; you > don't see a boot message yet > but you do see X booting after a while. Earlier talks were suggesting > that VGA was working (you > see the energy star logo and all that) so that's where my VGA BIOS > question came from.
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. > > I'm guessing you're referring to a VGA device (I don't have the class > > listing in front of me). Basically, when the BIOS starts up, it looks > > for one of these devices very early in the boot processes and sets it > > up. Then it does other initialization, followed by setup of other PCI > > devices (network, secondary gfx, etc.). > > That was VGA. :) From all this I understand that these legacy > addresses are broadcasted to all > cards on the PCI bus, or just automagically passed on to the 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. > initialised PCI VGA card. In any case, from a PCI card perspective I > don't have to initialise anything to 'see' this stuff. Correct? 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. > > I've done some OS-related development so I'm familiar with interrupt > tables. I'm just confused on the point of 'we hook into a table..', > how is the BIOS giving us that option? Is there some magic boot > sequence which enables us to get temporary control of the CPU? Does 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. > the BIOS asks for data from an address, which is then copied from the > EPROM into main memory and finally executed (so we can register > interrupts etc)? 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. > 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. > > 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. > > It hasn't been written yet. Our XP10 FPGA is hooked up to a SPI PROM, > > and we have all the logic in there to handle THAT part of it. So if > > someone were to write the VGA BIOS, we could put it in there, and then > > with all of the supporting logic ultimately in place, we can act as a > > boot console. > > So no boot screen until X starts, right? Right. > And does this mean that this > rom is platform dependent? 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. -- 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)
