[Open-graphics] from the simulation front - bochs and system simulation

[Petter Urkedal]

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.