-------------- Original message ---------------------- From: "Timothy Miller" <[EMAIL PROTECTED]> > On 7/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Since the Tool under this scenario is a stand-alone product, and not > > part > of any OGD or OGC board, it could be sold under its own part number, and be > permanently installed in any system that requires it. Maximum flexibility > for > the end user. It wouldn't even be tied to PCI graphics boards; it could be > compatible with any graphics board that uses a TRV10 or an FPGA emulation of > it. > In fact, the Tool board would be so generic, it could be used to configure > products that have nothing to do with graphics. > > Should we start talking about an "OGT1"? Should there be a little > > header > on OGD1 to permit plugging extra devices onto the end of the SPI chain? (I > really hesitate to think about any changes to OGD1 now, but an SPI header > might > be put on the features list for a possible OGD2.) > > I think you're making this MUCH more complicated than it needs to be.
For once, I'm going to argue with the guys doing the actual work. It's still your call, though. What's simple and what's complicated depends a good deal on what your experience is, and what situation you're facing. To an old board-level circuit designer like me, SPI is just about as simple as an interface can possibly get. It only takes a few pins, it's trivially simple to understand, and the parts to implement it are all off-the-shelf. It takes shift register chips and nothing else. You can even get them from the local Rat Shack. And NO coding is required, other than writing down the mode setting in binary. For somebody designing a board with a TRV10 IC in it, they can whip up an SPI initialization tool in 15 minutes with a handfull of chips from lab stock and one of those white nylon breadboarding blocks, if they don't like the standard tool, or if there isn't one available. For the OGA design team, it adds minimum complexity to the SPI port that's already there; reading the power-up mode from a tool just requires reading past the presumed end of EEPROM to see if something else is plugged into the end of the chain. Now, a consensus seemed to be emerging that the TRV10 and OGC1 should have some kind of minimal hook to allow for a way to set the video mode at power-up without host processor intervention, and maybe allow for a debug console too that doesn't depend on the host. The next question is whether that needs to be implemented in OGD1 so it can be tested. There's a good argument that OGD1 doesn't need it. The added on-chip logic is so simple, that it should be possible to verify it by desk-checking and simulation, without physically building it. (But maybe the SPI port is already on the 100-pin expansion header; I haven't dug into the schematic.) The thread on RS-232 as a configuration and debug interface is interesting. A couple of years ago I implemented exactly that feature, using a 68HC908AB32 microcontroller as an interface between an external RS-232 command port and an internal SPI tree. The AB32 has 1K of program space, which is adequate for a simple debugger language and some mode storage. If the configuration hook is the SPI port with a minimal generic ABI, the system integrator has the freedom to plug in an RS-232 tool, a board with a 120-position header and a shift register chain to read it in, or a locally designed setup tool to fit their own needs. > We have a programmable video controller and a programmable flash. > Let's just use them what they're designed for, which is to be > programmable. > > If they're booting in a BIOS-supported platform (like x86), we or they > can use a tool to mod the firmware to insert a custom video mode. If the system builder is in the common situation of using a PCI board in a system that can bring up a console without first setting a custom video mode, that would be the preferred method. Then all it takes is a utility program. But not everybody has that option. By the way, I don't think going back to Traversal or OGP to pre-install a custom mode would be very desirable. It would put a lot of paperwork burden on both the customer and the supplier to keep track of a whole lot of different part numbers that differ only by power-up video mode. It would deter re-flashing in the field by presenting the risk of creating a paperweight. It would make it difficult to re-purpose a board to fit a different display. Generally, it's a logistic briar patch. It's easier on everyone if setting the custom mode is put under the control of the system integrator or the end user. > > If they're booting in something else, the card won't be programmed > until the kernel driver hits it anyway. In that case, they can just > have the software configured correctly. In some systems, particularly minimum embedded systems with a naked application and no OS, it might not be possible to start work on the kernel or even the initialization code without first setting a custom video mode to get a text display. That's when the hardware configuration tool becomes an absolute necessity. If the long tail is to be accommodated, what's the very least amount of design work and hardware that would have to be added to OGA to support it? If there's anything simpler than just reading a little further out the SPI chain and looking for a preamble byte that introduces a custom mode, fine. If there's anything that imposes less cost on the standard product than an empty site for a 6-pin header to be field-installed, fine too. But that's my best shot. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
