On 2006-10-23, Rodolphe Ortalo wrote: > Le vendredi 20 octobre 2006 à 22:13 +0200, Petter Urkedal a écrit : > [...] > > I kind of expected we would have to write the PCI bus simulator > > ourselves, since these emulators don't need to interface with real > > hardware. (I read about the PCI bus, but I'm not sure how it looks like > > form the OS.) > [...] > > Why can't you do without such a PCI bus simulator? (The board simulator > model needs to interface with it?) It's not for the software only > simulator I guess? > Purely from the device driver software development point of view, we > can't stick to OS-provided PCI API? (From what I know, all device > programming is done via MMIO nowadays from the drivers, only the very > early initialization part uses another way via a few PCI config regs to > set up the MMIO spaces.)
I think it would be easy to just overload /usr/include/pci/pci.h, except that we sill need PCI bus emulation, which, taking the suggestion of your private mail, can be reduced to a wishbone interface. I was about to praise you suggestion, when I recalled what triggered the investigation of the emulator alternative. As I understand, MMIO means that we have to detect read/write to pages, and move corresponding pages in and out of the card. The Boehm-Demers-Weiser conservative garbage collector does dirty-bit detection on pages, so it's possible, but non-trivial. Using an emulator, we get that for free, and a native environment for the driver as a bonus. But, as said, I'm not sure how it will react to sporadic huge time-leaps when the Verilog simulation is triggered. > Btw, sorry if I said something stupid due to insuficient knowledge of > the OGP specs (maybe there is no MMIO... in which case I'll have to > check for a brown paper bag somewhere). So, I think you're right, but the MMIO part is tricky. > Furthermore, driver development is only the first step. Ensuring > adequate support at the Xorg and DRM level is needed nowadays to be a > first-class citizen in the graphics board space. (Open specs and open > documentation can do the rest afterwards - even without real hardware > mass production IMHO.) And more immanently, I presume the Xorg and DRM drivers will be needed to properly test the hardware. > > I guess OGD1 subsumes this whole discussion to a large extent since the > > remaining parts are in re-programmable FPGA. So if it isn't easy, maybe > > we should leave it for the present. > > Indeed, maybe sticking to the FPGA implementation is easiest in fine. > The main advantage of the simulator is that it would be very easy and > very cheap to distribute to many people; but that could prove too much > additional work too (mainly on the software simulator probably). > However, I still think that incorporating your own "device" into a > system simulator like qemu or bochs may have some amusing side effects > (like embedded applications developpers targeting an OGP-centric > accelerated feature set without knowing). Well, they have to buy a card then... Seriously, it would be a custom patch, or maybe a module in the Bochs case. Still, I was thinking about a quite generic PCI IO-space coupled with a Verilog-simulation, and that could be useful to other PCI-based hardware projects, as well. The OGP specific part would be the vanilla OGA driver loaded by the OS. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
